Stable 2.16 releases (dictator)

[Graham Percival]

I will officially introduce this next Tuesday, but since it's now
a hot topic, let's have an extra round of discussion and fixing
before then.

http://lilypond.org/~graham/gop/gop_3.html


*** Summary

Let’s appoint David Kastrup as the “benevolent dictator” of the
stable/2.16 git branch.

*** Motivation

(mostly copied from an email by David)

Releasing a stable release brings progress to LilyPond users.
LilyPond users are the most promising clientele for recruiting
future developers. People start actively working with the versions
they actually know and use. The less connections remain between
the versions in the hand of the users and the current development
source, the less likely their own work is suitable for eventual
inclusion in LilyPond. So we want to avoid having stable versions
that are quite outdated.

Regressions and bugs are a bad thing: we want to avoid them.
Detecting regressions and bugs is a good thing: we don’t want to
create incentives to avoid detecting them. What makes detecting
bugs a good thing? We gain the opportunity to fix them, and we
gain knowledge, the opportunity to evaluate their severity.

A stable release with severe bugs is a problem. A stable release
with some bugs and regressions is pretty much unavoidable. Let’s
accept that and leave it up to a human to judge whether bugs are
are “severe” or not.

*** Regressions

(mostly copied from an email by Trevor)

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.

To complete the discussion David and I were having about the
possibility of using revert as an option to fix a critical bug, I
looked at a few recent critical regressions, namely those which
caused Release Canditates 6 and 7 to be abandoned. None of these
could have been easily fixed by reversion, either because the fix
was complicated, the original source was too old for revert to be
safe, or the cause was external to LP. So reversion offers no easy
answer.

*** Details

The policy is: David Kastrup has sole authority over what goes
into stable/2.16 and which release(s) will have a version number
of 2.16.x, until 2012 Dec 31.

In more detail, this means:

   - he decides when to have 2.16.0.
   - he may classify issues as being issue-Critical, but he can
still make a 2.16.x release even if there are Critical issues if
he chooses to do so. Nobody else can denote issues as being
Critical.
   - when he wants have release, he will ask somebody to build a
release from the stable/2.16 branch.
   - he decides if, what, when to backport patches and have other
2.16.x releases.
   - translators do not merge or cherry-pick onto stable/2.16
unless specifically requested to do so. 


*** Further considerations

This could be considered to be an experiment. It is time- and
version-limited. In particular,

    - Development on git master continues as normal
    - in 2012 December, we will discuss what to do about the 2.16
branch in the future.
    - this policy does not forbid us from introducing 2.18 or 3.0
before 2012 Dec if we choose to do so.
    - this policy does not forbid us from developing other policies
for the 2.18 or 3.0 releases.
    - additional discussion about regtests, GLISS, development
roadmap, etc, are postponed until later. 


- Graham