lilypond-devel
[Top][All Lists]
Advanced

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

GOP2-2b - Stable 2.16.x releases (dictator)


From: Graham Percival
Subject: GOP2-2b - Stable 2.16.x releases (dictator)
Date: Tue, 17 Jul 2012 06:32:24 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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.
    - Classification of issues as being “Critical” takes place as
      normal, but he (and only he) may remove that label or even
ignore them completely and make a 2.16.x release despite Critical
issues.
    - 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.  nobody should merge
or cherry-pick from stable/2.16, either.
    - If he decides to quit before 2012 Dec 31, then we will have
      a new discussion about how to deal with the situation. 


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



reply via email to

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