From owner-freebsd-current@freebsd.org Sat Sep 19 18:23:29 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0C2423EB142 for ; Sat, 19 Sep 2020 18:23:29 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Btzbg4hPQz4Jkj; Sat, 19 Sep 2020 18:23:27 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-ej1-x62c.google.com with SMTP id nw23so12342529ejb.4; Sat, 19 Sep 2020 11:23:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p861cqtJ5rm7wdjRSuRe6wV6VuWs/tiFPUopuTGPvTs=; b=U8ybYM80P/W4mLgiBO2xv5dEyS5ybsMOO5utN9xGxhENC0xLOCzTEnPt5LZg5IOAkG 1AAXBWi5z/mOz6mobtzGxXIn9kdAEVeZ4kDK/9cmYlQZ79r7BBhg9PapLryp0rz1bSUj Lgd3e9MVR5+dME+WvZ488S+bh+3wnCkhTVsDWdsywIlB6L4kWhClFOIC2O03fbJ9wIsw H3tgAv87iXryCjSq1VeQcowlj5E3dAVjfOFRZdIqOgYc6NaBG+5qju+LLHGkrEZbF5vg +oYlyfnqSvxL8vXfcLBBFCAoweM/ucdolB9BrJeYijNpCyG4GCNZLGNEh67pW8S7/lX0 qBMA== X-Gm-Message-State: AOAM531Wl/vHf6rMvjGG0RjG/bEcb37ZtI1ZbQIcE6lcJ/V70/ftx6Tq S3UK91xzTgy9ZtJYbZBWXvxU/amPq4/wSjUGJQ== X-Google-Smtp-Source: ABdhPJwr5aroNH6xcGkEdqbc+v9Hpz9uKeItbxLoJYOxi+LJjW3055ik559bPnYAPbgWngfZymwnhu+qZNDF6UuV1xQ= X-Received: by 2002:a17:906:c411:: with SMTP id u17mr41223434ejz.319.1600539805118; Sat, 19 Sep 2020 11:23:25 -0700 (PDT) MIME-Version: 1.0 References: <20200902045939.GA15897@eureka.lemis.com> <20200902060117.GG53210@home.opsec.eu> <20200902063136.GA47543@troutmask.apl.washington.edu> <20200902164706.GA49777@troutmask.apl.washington.edu> <5c89b4d27281f5dfffc3252a90013b0ac6c763d7.camel@freebsd.org> <5c832482-b2bc-47e4-8762-8f5a886d5f11@www.fastmail.com> <68585ca4-5ca4-40d3-b2f4-67ff3b35b6ae@www.fastmail.com> <0be2ae57d1c58e2091f4cc4484731df0@bsdforge.com> <967D73EA-880E-413D-B748-62A406C46524@FreeBSD.org> <9f89dc553e7d7b0884c2862329bdfeae@bsdforge.com> In-Reply-To: From: Zaphod Beeblebrox Date: Sat, 19 Sep 2020 14:23:13 -0400 Message-ID: Subject: Re: Plans for git To: Warner Losh Cc: Chris , Kristof Provost , FreeBSD Current X-Rspamd-Queue-Id: 4Btzbg4hPQz4Jkj X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.05)[-1.049]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from]; NEURAL_HAM_SHORT(-0.75)[-0.750]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 18:23:29 -0000 Actually, frankly, yes. Nearly the first cogent summary I've found so far. On Sat, Sep 19, 2020 at 2:22 AM Warner Losh wrote: > > > On Fri, Sep 18, 2020, 11:31 PM Zaphod Beeblebrox > wrote: > >> Hrm. Maybe what I hear others saying, tho, and not entirely being >> replied to is just a nice concise document of the why. What I hear you >> saying is that GIT has momentum and that it's popular... (and I accept that >> --- it is evidently true), but then I hear handwaving about features, but >> no list of features that are a clear win/loose. >> > > Apache has switched to git from subversion. They are the current > caretakers of subversion so it's future is very much in doubt. > > Git have more support for newer CI tools than subversion. This will allow > us, once things are fully phased in, to increase the quality of the code > going into the tree, as well as greatly reduce build breakages and > accidental regressions. > > Gits merging facilities are much better than subversion. You can more > easily curate patches as well since git supports a rebase workflow. This > allows cleaner patches that are logical bits for larger submissions. > Subversion can't do this. > > Git can easily and robustly be mirrored. Subversion can be mirrored, but > that mirroring is far from robust. One of the snags in the git migration is > that different svn mirrors have different data than the main repo or each > other. Git can cryptographically sign tags and commits. Subversion cannot. > > Mirroring also opens up more 3rd party plug ins. Gitlab can do some > things, Github others, in terms of automated testing and continuous > integration. Tests can be run when branches are pushed. Both these > platforms have significant collaboration tools as well, which will support > groups going off and creating new features for FreeBSD. While one can use > these things to a limited degree, with subversion mirrored to github, the > full power of these tools isn't fully realized without a conversion to git. > > All of this is before the skillset arguments are made about kids today > just knowing git, but needing to learn subversion and how that has had > increasing been a source of friction. This argument is the closest one to > being handwavy since I've not voted the data showing the growing proportion > of projects using git (iirc, it's 85% or 90%). > > These are the main ones. The three down sides are lack of $FreeBSD$ > support and tags in general. Git has a weaker count of commits than > subversion. And the BSDL git clients are less mature than the GPL'd ones. > > Certainly the only clear things a quick search turns up that seem relevant >> is that GIT is GPL2.0 and SVN is Apache2.0. This was enough for LLVM vs >> GCC and the repository is a core function, but I suppose not a necessary >> function for forked projects that can't abide, so... >> > > OPENBSD has got, which is being ported in earnest. It has an agreeable > license. > > Anyways... some concise record of thoughts might calm the gnawing >> sensation in my gut... >> > > Yes. I've started doing a series of short videos explaining the change, > why we are doing it and what to do in the new world order. I'll be doing > blog entries as well as turning that material into handbook entries. I have > some of those written. > > Does this help? > > Warner > > On Thu, Sep 3, 2020 at 4:19 PM Warner Losh wrote: >> >>> On Thu, Sep 3, 2020 at 1:32 PM Chris wrote: >>> >>> > On 2020-09-03 11:33, Kristof Provost wrote: >>> > > On 3 Sep 2020, at 19:56, Chris wrote: >>> > >> Why was the intention to switch NOT announced as such MUCH sooner? >>> > >> >>> > > There was discussion about a possible switch to git on the >>> freebsd-git >>> > > mailing >>> > > list as early as February 2017: >>> > > >>> > >>> https://lists.freebsd.org/pipermail/freebsd-git/2017-February/000092.html >>> > > >>> > > Ed gave a talk about FreeBSD and git back in 2018: >>> > > https://www.youtube.com/watch?v=G8wQ88d85s4 >>> > > >>> > > The Git Transition Working group was mentioned in the quarterly >>> status >>> > > reports a >>> > > year ago: >>> > https://www.freebsd.org/news/status/report-2019-07-2019-09.html >>> > > and >>> > > https://www.freebsd.org/news/status/report-2019-04-2019-06.html >>> > It appears to me that the references you make here all allude to >>> > _investigation_ >>> > of a _possibility_ as opposed to a _likelihood_, or an _inevitable_. >>> > IMHO a change as significant as this, which will require tossing years >>> of >>> > tooling >>> > out the window, and an untold amount of _re_tooling. Should have >>> created an >>> > announcement at _least_ as significant as a new release gets on the >>> mailing >>> > lists. >>> > >>> >>> Yes. We've been working on this for years. We've been working on the >>> retooling in earnest for the last 6 months. We didn't make an >>> announcement >>> because we wanted to have most of the pieces in place before we did that. >>> We've been doing the multi-year process for multiple years now. I'll also >>> point out that only the 'git' people showed. A number of other ideas were >>> suggested, but nothing else was stood up in a serious way (hg came the >>> closest to setting up an exporter). Since there was really no >>> alternatives >>> being proposed to git, the process was less visible than if we'd had to >>> have had a hg vs git bake off. One step has lead to the next, with much >>> status reporting done for years. >>> >>> Subversion, btw, is not viable in the long run. The Apache foundation has >>> moved all its projects from svn to git. The velocity of features with svn >>> has diminished, and the number of CI/CT/etc tool sets that supported svn >>> well has been dropping over time. It's also been identified as a barrier >>> to >>> entry for the project. Sure, some people climb the learning curve to >>> learn >>> and understand it, but our survey data has shown that for every one that >>> did take the time, many others did not and simply didn't contribute. >>> >>> All of these issues have been discussed at length at conferences for the >>> last 5 years at least, with increasing levels of sophistication. Had >>> there >>> been a BSDcan this year, I'd hoped to do a talk / BOF on this to help >>> socialize the ideas and to get people's feedback in real time (rather >>> than >>> the slow and difficult process of getting it just in email). >>> >>> We've also talked about this in the BSD office hours and core election >>> forums over the past year. >>> >>> We've been rolling out the beta git repo now for 3 months. People have >>> found issues and we've been correcting them. We've heard from people that >>> their automated tooling needs a bit of transition time, so we'll be >>> exporting the stable/11 and stable/12 branches back into subversion (and >>> the release branches) after the conversion for the life of those >>> branches, though we don't plan on doing it for the current nor stable/13 >>> branches (due to the inefficiencies of git-svn, we need separate trees >>> for >>> each, and each tree takes over a day to setup). We know we need some >>> better >>> docs (we have some decent preliminary ones, but there's some missing bits >>> in them, and they are too long for more casual users). We need to spell >>> out >>> different commit policies, how we're going to have to shift our "MFC" >>> terminology because that's very CVS/SVN centric (in git a merge means a >>> more specific thing than it does in svn. A cherry-pick in git is also >>> called a merge in svn, for example). We need to document to the >>> developers >>> how to make the shift (this doc is mostly complete and was posted >>> earlier, >>> though it could use some TLC). We'd hoped to have the documents done, the >>> policies written and vetted and have a good test system before making an >>> announcement. The last thing I wanted was to make a big announcement, >>> only >>> to fail to deliver. And since each step of the process followed >>> naturally, >>> there wasn't a clear A/B decision point where an announcement could have >>> been generated. We were getting close to publishing the final schedule >>> when >>> this thread popped up, though, since it is finally feeling like it will >>> be >>> real soon. I also had hoped to refine things so that existing developers >>> and users would have only minor disruption at the cut over because things >>> were well documented. >>> >>> And once we have all the basics of phase 1 (which is just going to be 'do >>> FreeBSD's current workflow in git, making minimal changes initially), >>> we'll >>> start on the refinements to the workflow that will help improve the >>> quality >>> of code, make it easier to integrate changes, etc. There's quite the >>> diversity of views and opinions in the larger open source world on what >>> best practices are here, with different projects doing different things. >>> It >>> will take some time for the project to adopt these new tools, new work >>> flows and realize that in some cases a diversity of tools can be an >>> advantage rather than a liability. This may be especially true as the >>> needs >>> of the ports tree differ from the needs of the src tree and what's >>> optimal >>> for one may not work too well for the other. >>> >>> So a lot of my reaction in the past few days has been frustration that >>> this >>> came up about a week before we had all our ducks in a row to talk about >>> it >>> effectively and talk about the transition plans. I apologize for being so >>> snarky about it. >>> >>> Warner >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to " >>> freebsd-current-unsubscribe@freebsd.org" >>> >>