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

[Jeff Law <law at redhat dot com>]

On Mon, 2019-12-16 at 16:42 -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Mon, Dec 16, 2019 at 03:13:49PM -0700, Jeff Law wrote:
> > On Mon, 2019-12-16 at 15:59 -0600, Segher Boessenkool wrote:
> > > 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.
> > Perhaps.  But there's also limits to what scripts can do.
> 
> Absolutely.  Just this trust in complicated things is very misplaced, in
> my opinion.
It's as much about trusting the people as much as the tools.  While I
don't have the opportunity to work with Joseph all that much, I have
seen his work and attention to detail for 20+ years.   When he says
that, in his opinion, the reposurgeon conversion is already a better
conversion than Maxim's conversion, I absolutely trust him. 
Furthermore I trust that if there are significant issues that he'll
engaged to fix them.


> > > 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.
> > I'd disagree.  THe experience and testsuites from that system are a
> > significant benefit. 
> 
> That isn't what I said.  I said that freshly constructed complex software
> will have more and deeper errors than stupid simple scripts do (or I
> implied that at least, maybe it wasn't clear).  And I only say this
> because the opposite was claimed, which is laughable imnsho.
But it's not that freshly constructed, at least not in my mind.  All
the experience ESR has from the python implementation carries to the Go
implementation.

And the "simple scripts" argument dismisses the fact that those scripts
are built on top of complex software.  It just doesn't hold water IMHO.

Where I think we could have done better would have been to get more
concrete detail from ESR about the problems with git-svn.  That was
never forthcoming and it's a disappointment.  Maybe some of the recent
discussions are in fact related to these issues and I simply missed
that point.

I do think we've gotten some details about the "scar tissue" from the
cvs->svn transition as well as some of our branch problems.  It's my
understanding reposurgeon cleans this up significantly whereas Maxim's
scripts don't touch this stuff IIUC.

> 
> > > > * 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.
> > Sorry, have to disagree here.  I think what Richard has done is a
> > significant step forward. 
> 
> We talked about it for days, and as far as I understand it Richard agreed.
When Richard and I spoke we generally agreed that we felt a reposurgeon
conversion, if it could be made to work was the preferred solution,
followed by Maxim's approach and lastly the existing git-svn mirror. 
If I'm mis-representing Richard's position I hope he'll chime in and
correct the record.

> 
> But, there is no way I can verify this yet, or is there?  Is there a repo
> we can look at?  Something close to final.
I think Joseph posted something good enough to verify.  There's still
work going on, but I'd consider the outstanding issues nits and well
within the scope of what can reasonably still be changing.  I would
have had a similar position for Maxim's scripts if there were minor
changes still happening with them.


Jeff