On Mon, 2019-12-16 at 09:36 -0600, Segher Boessenkool wrote:
> On Mon, Dec 16, 2019 at 02:13:06PM +0000, Joseph Myers wrote:
> > On Mon, 16 Dec 2019, Segher Boessenkool wrote:
> > 
> > > Most of us are perfectly happy even with the current git mirror, for
> > > old commits.  We want "real" git to make the workflow for new commits
> > > better.
> > > 
> > > No more delays, _please_.
> > 
> > The timetable is a useful guideline.  It should not be our master when 
> > there are clear improvements with implementations already available; 
> > waiting to the actual end of stage 3 makes sense (when waiting another 
> > year would not make sense).  When we're talking about something to be used 
> > for the next 20 years we should make sure to get it right.
> 
> We should not take five years to get it done.
> 
> And the current mirror is "right", already, as Jeff said at the Cauldron
> (a minute before we unanymously decided to do the conversion soon; this
> is over three months ago already).
Yup.   I want to convert sooner, not later.  I don't mind slipping a
little for validation work or because it doesn't line up with our
schedules.  I don't want to slip for major changes in the tooling.

My preference has always been, in order, reposurgeon, Maxim's scripts
and the existing mirror.  However, I'm confident that all of them will
be sufficient for our needs.


> > All conversions clearly need more validation work.
> 
> No, I do not agree with that.  We have had the opportunity to look at
> Maxim's conversions for months already, since before the Cauldron, and
> it has been perfectly adequate from the start imnsho, and it has been
> improved a little since even.
Yet Joseph just indicated today Maxim's conversion is missing some
branches.  While I don't consider any of the missed branches important,
others might.   More importantly, it raises the issue of what other
branches might be missing and what validation work has been done on
that conversion.


> 
> > That missing branches 
> > in Maxim's conversion could be noted only today clearly shows that 
> 
> ... clearly shows that *no one cares* about those branches.
> 
>  (and 
> > conversions with an ad hoc script need much more thorough, trickier 
> > validation because you don't benefit from knowing the tool has worked for 
> > other conversions).
> 
> Reposurgeon is ad-hoc as well, and the current implementation is a
> complete rewrite, and not proven *at all*.  At least Maxim's scripts are
> just that: scripts, using some very well-tested very widely used tools
> as building blocks.
I wouldn't really classify it that way.  reposurgeon has significant
history.  Are we using a rewrite, yes, but there's extensive experience
behind it as well as testsuites to validate the work.


> 
> > > If the reposurgeon conversion is not ready now, then it is too late
> > > to be selected.
> > 
> > I believe it's at least as ready as Maxim's.
> 
> I do not agree.  You say the reposurgeon conversion is not ready today.
> Maxim's conversion has been ready for many months.
Actually Joseph's position is that reposurgeon is already beyond
Maxim's conversion in terms of quality.

My interpretation of the messages flying by is they're ironing out some
details on the edges, but I don't think those are major intrusive
changes.

jeff

Reply via email to