Re: Proposal for the transition timetable for the move to GIT

[Segher Boessenkool <segher@kernel.crashing.org>]

Hi,

On Mon, Dec 16, 2019 at 05:07:48PM +0000, Joseph Myers wrote:
> 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.

Please do that for Maxim's conversion as well then?

(If the way you do the verification requires reposurgeon, the
verification methodology itself is fatally flawed).

> 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).

Or the other way around.

> 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.

I totally do not agree.  Black boxes are not safe.  *New* black boxes
are even worse.

I trust scripts that have low internal complexity much better.

There is absolutely no reason to trust a system that supposedly was
already very mature, but that required lots of complex modifications,
and even a complete rewrite in a different language, that even has its
own bug tracker, to work without problems (although we all have *seen*
some of its many problems over the last years), and at the same time
bad-mouthing simple scripts that simply work, and have simple problems.

> * 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 long as the original commit message is kept, verbatim, and you only
add a new summary line, all is fine.  If not -> nope, not okay.

> * 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.

This, I don't agree with at all either: having some lean-and-mean
scripts that worked for the GCC conversion will be at least as helpful
for another conversion as a "general" tool that first requires you to
build a custom machine before you can use it properly, would be.


Anyway: yes, please verify all conversion candidates for your criteria.
Thanks!


Segher