Re: Issue 2648 in lilypond: Repeat Dots and Staff Size in 2.15.41

[Trevor Daniels]

David Kastrup wrote Tuesday, July 10, 2012 1:19 PM


> "Trevor Daniels" <address@hidden> writes:
> 
>> We have the technology to identify the commits that introduce bugs
>> fairly easily.  Perhaps once the first release candidate is made we
>> simply say any commit that introduced a critical regression bug after
>> that is simply reverted, and the originator invited to resubmit after
>> the next stable is released.
> 
> After the stable release is before the stable release.  We can't freeze
> development while we are unable to get a sane release process going.
> That would be, like, permanent.

That's not what I said.  I said "once the first release candidate is made".
After that point we deal with new regressions by reverting, and don't
start a new countdown, rather than starting a new countdown only
after the bug is fixed, as now.  That would guarantee we get a stable release
within the period we allow for testing the release candidate.  Although
if this were adopted we might extend the testing period a little.
 
> One could try such a revert strategy on a stable release _branch_, but
> it is not unlikely to lead to cascades of reverts, since quite a few
> fixes are also intended to cure regressions by themselves.  And reverts
> of increasingly older commits have increasingly stranger interactions
> with developments that happened in between (and that does not just mean
> merge conflicts).

If such a complication did arise then that would justify requiring a
proper fix, in which case a new countdown would begin only
after the fix was in.   

I guess we really need an analysis of recent critical bugs to come
to a rational conclusion.

Trevor