Re: Plans for git

Just My 2¢… 

> On Sep 3, 2020, at 5:19 PM, Warner Losh <imp_at_bsdimp.com> wrote:
> 
> On Thu, Sep 3, 2020 at 1:32 PM Chris <bsd-lists_at_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.

The thing that bugs me most is the fact that this all happened and was done without bringing public attention until recently. It wasn't the fragility of the argumentations nor the feeling that we are now following the group. Many of 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.

-- 
rollingbits — 📧 rollingbits_at_gmail.com 📧 rollingbits_at_terra.com.br 📧 rollingbits_at_yahoo.com 📧 rollingbits_at_globo.com 📧 rollingbits_at_icloud.com