[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 17:33:49 +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 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.
>> 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).
>
> If such a complication did arise then that would justify requiring a
> proper fix, in which case a new countdown would begin only after the
> fix was in.
>
> 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.
Then tell me again that I am coming to irrational conclusions.
It is not like we are talking about surprise developments here.
--
David Kastrup
clear policy discussions (was: Issue 2648 in lilypond: Repeat Dots and Staff Size in 2.15.41), Graham Percival, 2012/07/10
- Re: clear policy discussions, David Kastrup, 2012/07/10
- Re: clear policy discussions, Graham Percival, 2012/07/10
- Re: clear policy discussions, David Kastrup, 2012/07/10
- Re: clear policy discussions, Graham Percival, 2012/07/10
- Re: clear policy discussions, David Kastrup, 2012/07/11
- Re: clear policy discussions, Janek WarchoĊ, 2012/07/13
- Re: clear policy discussions, David Kastrup, 2012/07/13