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.
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... Anyways... some concise record of thoughts might calm the gnawing sensation in my gut... On Thu, Sep 3, 2020 at 4:19 PM Warner Losh <i...@bsdimp.com> wrote: > On Thu, Sep 3, 2020 at 1:32 PM Chris <bsd-li...@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 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
