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

[Janek Warchoł]

On Wed, Jul 11, 2012 at 6:07 PM, David Kastrup <address@hidden> wrote:
> Janek Warchoł <address@hidden> writes:
>
>> 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.

Well, this isn't what i meant to be the "spirit" of my proposal.
My idea for the "spirit" of the new policy is:
"Regressions are bad, we cannot ignore them - we have to fix them.
But we aren't their slaves, we don't have to fix them immediately."

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

ok, good points.  So, i suggest to additionally give Project Manager
the power to "upgrade" any regression against current stable
discovered to critical.

Let me rephrase my suggestion then:
Regressions can be critical (prevent new stable) or not.  The default
behaviour is to mark regressions against current stable as not
critical (?), and regressions against previous stable as critical.
(This is to ensure that regressions won't disrupt release process, but
also won't stay around forever.)
Any developer (i.e. has push access) is free to upgrade/downgrade a
regression's status to critical/non-critical.  Other developers are
free to discuss this.  If in doubt, the decision should be made by
Project Manager, who is advised to ask senior developers for their
opinions.  Project Manager's decision should be considered final for
at least a month (to avoid endless debates, but also allow reopening
if necessary).

What about this?  It gives people power, yet allows
"i'm-feeling-monkeyish" following of guidelines (with hopefully
reasonable outcome nevertheless).  It also gives Project Manager
control, but not too much of it and not too much responsibility.
I feel this is a significantly better proposal than my first one.

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

Good point.  I suggest 6 months, then, with preferred release times to
be May and November (that's because summer tends to be most active
time - let's give big summer projects time to mature and stabilise).
Janek