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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
