Re: Plans for git

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.

Warner