Date: Thu, 3 Sep 2020 14:18:54 -0600 From: Warner Losh <imp@bsdimp.com> To: Chris <bsd-lists@bsdforge.com> Cc: Kristof Provost <kp@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Plans for git Message-ID: <CANCZdfqoFC9vD7ue=7FfYbaxYDivFxRX45DQNVRuidj%2BDvq_2A@mail.gmail.com> In-Reply-To: <9f89dc553e7d7b0884c2862329bdfeae@bsdforge.com> References: <CAPyFy2CTTecRJDnXNvF%2BM2%2BaLWJpA%2BEdG43ZeU3qwsCruecoFA@mail.gmail.com> <20200902045939.GA15897@eureka.lemis.com> <20200902060117.GG53210@home.opsec.eu> <20200902063136.GA47543@troutmask.apl.washington.edu> <CAPyFy2ANWEiA2ndE6qr_kY=sPuY%2BeaAZg=apWo0OZPVC7pkwkg@mail.gmail.com> <20200902164706.GA49777@troutmask.apl.washington.edu> <CANCZdfp8b78yNB8S2j1xHUKEz5iGNvdBGnw774_sXXtN9ucrSw@mail.gmail.com> <5c89b4d27281f5dfffc3252a90013b0ac6c763d7.camel@freebsd.org> <5c832482-b2bc-47e4-8762-8f5a886d5f11@www.fastmail.com> <e0b8e48e2942c019e05bdc21a6502379235f9073.camel@freebsd.org> <68585ca4-5ca4-40d3-b2f4-67ff3b35b6ae@www.fastmail.com> <0be2ae57d1c58e2091f4cc4484731df0@bsdforge.com> <967D73EA-880E-413D-B748-62A406C46524@FreeBSD.org> <9f89dc553e7d7b0884c2862329bdfeae@bsdforge.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 3, 2020 at 1:32 PM Chris <bsd-lists@bsdforge.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqoFC9vD7ue=7FfYbaxYDivFxRX45DQNVRuidj%2BDvq_2A>