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

[David Kastrup]

"Trevor Daniels" <address@hidden> writes:

> David Kastrup wrote Tuesday, July 10, 2012 12:21 PM
>
>>> address@hidden: Repeat Dots and
>>> Staff Size in 2.15.41
>>> http://code.google.com/p/lilypond/issues/detail?id=2648
>>>
>>> This bug first appeared in 2.15.40, so is a critical regression.
>> 
>> I mean, we have too few categories for regressions.  I can see the
>> following:
>> 
>> a) Precludes work (patchy/staging catches most of those)
>> b) Precludes releases
>> c) Precludes a stable release
>> d) An eventual fix should be backported to last stable
>> 
>> My personal opinion is that we overuse category c) because we don't want
>> to think about d).  It's nice aiming for a stable release that will
>> never need a single backport or regression fix in its life time.
>
> I would have no problem with making a new stable release with
> the expectation that it _might_ contain regressions, but it would be
> wrong to make a stable release containing _known_ regressions.

I consider it likely that 2.14.2 contains more known regressions against
2.12.3 or later than 2.15.41 does.  If a "regression" is not important
enough to make a backport to the _current_ _stable_ _release_, why is it
important enough to completely kill the next stable release?

> After all, that is the point of making release condidates, isn't it -
> to identify new bugs so they can be fixed before the stable is
> released?

No.  The point of making release candidates is to identify bugs of a
severity that precludes making a stable release.  Not just any old bug.

>> But that nicety pales against the garishness of not giving the users
>> anything ever.
>
> I agree with your general sentiment - we need to find a way of
> controlling the introduction of new bugs as a new stable become due.

A new stable is always due, and new bugs are introduced always.  We need
to adequately deal with the consequences.

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

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

-- 
David Kastrup