Proposal for the transition timetable for the move to GIT

[Joseph Myers]

On Mon, 16 Dec 2019, Jeff Law wrote:

> On Mon, 2019-12-16 at 11:29 +0000, Joseph Myers wrote:
> > On Mon, 16 Dec 2019, Mark Wielaard wrote:
> > 
> > > Should we go with the gcc-reparent.git repo now?
> > 
> > I think we should go with the reposurgeon conversion, with all Richard's 
> > improvements to commit messages.  gcc-reparent.git has issues of its own; 
> > at least, checking the list of branches shows some branches are missing.  
> > So both conversions can still be considered works in progress.
> So it seems like your position is that the reposurgeon conversion is as
> good as or better than conversion from Maxim's scripts.

Yes.  It should be possible to confirm branch tip conversions and other 
properties of the repository (e.g. that all branch tips are properly 
descended from the first commit on trunk except for the specific branches 
that shouldn't be) once my current conversions have finished running.

I think there may well be things to *learn* from Maxim's conversion to 
improve the reposurgeon one further (if they don't take that long to 
implement).  In particular, we should look carefully at the commit 
attributions in both conversions and Maxim's may well give ideas for 
improving the reposurgeon changelogs command (Richard came up with three 
ideas recently, which I've just filed in the reposurgeon issue tracker).  
But I also think:

* reposurgeon is a safer approach than ad hoc scripts, provided we get 
clean verification of basic properties such as branch tip contents.

* Richard's improvements to commit messages are a great improvement to the 
resulting repository (and it's OK if a small percentage end up misleading 
because someone used the wrong PR number, sometimes people use the wrong 
commit message or commit changes they didn't mean to and so having some 
misleading messages is unavoidable).

* As we're part of the free software community as a whole rather than 
something in isolation, choosing to make a general-purpose tool work for 
our conversion is somewhat preferable to choosing an ad hoc approach 
because it contributes something of value for other repository conversions 
by other projects in future.

-- 
Joseph S. Myers
joseph@codesourcery.com