[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Kastrup
Subject: Re: Issue 2648 in lilypond: Repeat Dots and Staff Size in 2.15.41
Date: Tue, 10 Jul 2012 18:58:47 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

"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:>,
>> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]