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

[Trevor Daniels]

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