Date: Sat, 19 Sep 2020 17:44:50 -0300 From: =?utf-8?Q?Lucas_Nali_de_Magalh=C3=A3es?= <rollingbits@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Chris <bsd-lists@bsdforge.com>, Kristof Provost <kp@freebsd.org>, FreeBSD Current <FreeBSD-current@freebsd.org> Subject: Re: Plans for git Message-ID: <C3E06517-66A9-4486-BED2-54FC7CD69AF9@gmail.com> In-Reply-To: <CANCZdfqoFC9vD7ue=7FfYbaxYDivFxRX45DQNVRuidj%2BDvq_2A@mail.gmail.com> References: <CANCZdfqoFC9vD7ue=7FfYbaxYDivFxRX45DQNVRuidj%2BDvq_2A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Just My 2=C2=A2=E2=80=A6=20 > On Sep 3, 2020, at 5:19 PM, Warner Losh <imp@bsdimp.com> wrote: >=20 > =EF=BB=BFOn Thu, Sep 3, 2020 at 1:32 PM Chris <bsd-lists@bsdforge.com> wro= te: >=20 >>> 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? >>>>=20 >>> There was discussion about a possible switch to git on the freebsd-git >>> mailing >>> list as early as February 2017: >>>=20 >> https://lists.freebsd.org/pipermail/freebsd-git/2017-February/000092.html= >>>=20 >>> Ed gave a talk about FreeBSD and git back in 2018: >>> https://www.youtube.com/watch?v=3DG8wQ88d85s4 >>>=20 >>> 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 a= n >> announcement at _least_ as significant as a new release gets on the maili= ng >> lists. >>=20 >=20 > 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. >=20 > 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 t= o > 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. >=20 > 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). >=20 > We've also talked about this in the BSD office hours and core election > forums over the past year. >=20 > 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 bette= r > 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 ou= t > 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 whe= n > 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. >=20 > 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'l= l > start on the refinements to the workflow that will help improve the qualit= y > 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. I= t > 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 need= s > 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. >=20 > So a lot of my reaction in the past few days has been frustration that thi= s > 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. The thing that bugs me most is the fact that this all happened and was done w= ithout bringing public attention until recently. It wasn't the fragility of t= he argumentations nor the feeling that we are now following the group. Many o= f the initiatives that didn't went forward and have been removed I evaluated= as a positive point in the project, even. I saw many projects and ideas die= due to bad management and lack of action, not for the kind of argumentation= presented. --=20 rollingbits =E2=80=94 =F0=9F=93=A7 rollingbits@gmail.com =F0=9F=93=A7 rollin= gbits@terra.com.br =F0=9F=93=A7 rollingbits@yahoo.com =F0=9F=93=A7 rollingbi= ts@globo.com =F0=9F=93=A7 rollingbits@icloud.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C3E06517-66A9-4486-BED2-54FC7CD69AF9>