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

No _known_ regressions was our rule.

> So all regressions discovered subsquently are new, in the sense that
> they were previously unknown.

I think we both could spend our time better than playing word games.

> 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 addressed this already in a part you did not bother quoting in your
previous reply.

Anyway, a revert will have consequences requiring another test phase.
So there is little timing advantage for not just taking the proper fix,
which gets more exposure to developer testing than a diverged release
candidate.  The life time of a typical regression fix has been rather
long: the usual clincher for stopping the next release candidate are
_unrelated_ regressions.

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

We would not want to rush anything, would we now?

-- 
David Kastrup