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

[Trevor Daniels]

David Kastrup wrote Tuesday, July 10, 2012 4:33 PM


> "Trevor Daniels" <address@hidden> writes:
> 
>> 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.
> 
> Uh, no.  By far most regressions we had were old regressions.

No, a stable release candidate can only be made when there
are no extant regressions.  So all regressions discovered
subsquently are new, in the sense that they were previously
unknown.  It is these that I am suggesting be "fixed" by simply
identifying the commit that introduced them and reverting it
(unless there are complications, as discussed earlier.)  If the
new regression can be fixed by reverting I suggest there is no
need to restart the count-down.  This should greatly shorten
the time to get a stable release out.

>> I guess we really need an analysis of recent critical bugs to come
>> to a rational conclusion.
> 
> <URL:http://news.lilynet.net/?The-LilyPond-Report-26#the_road_to_2_16>,
> scroll down to "Critical issues", unfold the table, read the article.

Yes, that was an excellent start, but we still need to tie this
in to the times release candidates were made, and then see
if subsequent regressions could have been successfully 'fixed'
by reverting, before we can come to a conclusion about my
suggestion (which is what I meant by "rational conclusion").

Trevor