Re: GOP2: 2 - Stable releases and roadmap (radical change)

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> On Tue, Jul 10, 2012 at 11:50 PM, Trevor Daniels <address@hidden> wrote:
>> So far there have been c. 75 critical regressions under the
>> current definition of 'critical' since 2.14.  All but one have been
>> fixed, many of them promptly.  This prompt attention IMO
>> is due only to the fact that they were deemed to block a
>> stable release.  If the only criterion is that the release compiles
>> the (extended) regtests satisfactorily, then I doubt that adequate
>> attention will be directed to bugs discovered after the release
>> that would be deemed critical on the current definition.  That
>> would seriously degrade the quality of our stable releases.
>
> This is a valid concern.
> What about something like this:
> when a regression against latest stable is found, it's not marked as
> critical (as Graham suggests).  However, when we make a stable
> release, all regressions present in the tracker become critical.  In
> other words, if current unstable is, say, 2.17.x, regressions against
> 2.16 aren't critical (don't prevent releasing 2.18), but still-unfixed
> regressions against 2.14 are critical.

I don't think that makes much sense.  It means that regressions become
important _after_ stable releases.  Also it means that it becomes hard
to classify newly discovered regressions: at the current point of time,
LilyPond 2.12 does not even compile on current GCC compilers.

I still maintain that the main problem right now is that all regressions
are considered equally important, and uniformly more important than
bugs.

For example, when the stems don't reach shapenote heads on quarternotes
(while the situation before the stem-inducing regression was that they
did, but instead did not connect on eighths), that is enough to not give
users access to LilyPond 2.16.  That typesetting in connection with
grace timing is still broken is much more severe, but it does not
preclude us from making a release.

> This way we are "forced" to fix all regressions (sooner or later), but
> we eliminate the element of surprise that is so annoying in current
> system.

Regressions are something we want to keep in check, but not at any cost.
Of course, the way to absolutely guarantee no regression is to never
release.  That is the course we are currently taking.

> Things may break, but we won't leave them broken too long.  Since the
> lack of "surprises" should allow frequent stable releases, all
> regressions should be fixed pretty quickly.  We could actually adopt a
> policy of aiming to have a stable release each 3 months, which should
> help with that.
>
> How do you like it?

3 months is not a useful cycle for a stable release.  How do you expect
something like the skyline patches to stabilize in such an amount of
time?  It needs retuning hosts of parameters as one consequence.  It
would also mean that if we want to provide reasonable update paths to
software distributions with a life time of a year, we would need to
maintain backports for about four stable versions at a time.

-- 
David Kastrup