Stable release state

[David Kastrup]

With the recent batch of material with missing documentation, extensive
code changes and new functionality without previous exposure and moving
interfaces (like
commit 88d306d9c5666b5ade4a136df29cca19c5ff5ed7
Author: Mike Solomon <address@hidden>
Date:   Sat Apr 6 09:54:58 2013 +0200

    Break slurs between alternative endings in repeats; issue 1698.
    
    Create new event-types BreakPhrasingSlurEvent BreakSlurEvent,
    and a music-function \free so that users can create them.
    Create these event-types in the volta-repeat-iterator to break
    slurs between alternatives in a \repeat volta structure.

) it is clear that master has stopped being suitable for turning into a
stable branch.  There are several ways forward, none of them
particularly endearing.

a) cut the stable branch before the last batch of changes and accumulate
only bug fixes of simple nature and/or regression fixes into it from now
on.  The problem with that approach is that we have a _lot_ of
outstanding bug fixes, partly because we have not a single developer who
could be bothered about catering even for trivial documentation fixes
like <URL:http://code.google.com/p/lilypond/issues/detail?id=3151>
(dormant for two months after reporting, and we have quite a few of that
class pending).  That basically means that I'll be responsible for
fixing all of the Frog-class bugs necessary to get into release state,
and also cherry-pick all of those bugs.  Needless to say, this will turn
to be a _lot_ of work over the course of months.

There won't be useful input from users of master since master is allowed
to seriously diverge and those changes will capture the attention of
testers more than long-standing small fixes.

b) scrap the idea of a stable release for this year.  Given the already
wide-spread friction about things like the new override syntax, this is
not a particularly enticing option either.

At the current point of time, I see this as the most likely outcome.
Developers simply can't be interested in doing and not doing what would
be important for a stable release.  The minute I let my guard down for
the duration of a countdown since I actually have _more_ work to do than
to replace common sense for everybody else if a stable release is
supposed to get out, stuff is dumped into master that is not suitable
for inclusion into a stable release.

c) call something a stable release that is quite unfit for that purpose.
This is not really a good option since it means that one has to maintain
cherry-picking fixes into the stable branch and releasing "stable"
releases until the release becomes stable.  But that is the exact same
maintenance hog that option a) would be, just with the addition of
pretending an initial unsuitable release is "stable".

d) get someone else to cater for making a stable release so that I am
not the only one running after release quality.  I don't really see this
working out: before I took over the 2.16 release process, we had release
candidates for over a year being called and called off again, based on a
semi-automatic quality criterion.  We'd need a reasonably competent
developer to judge scope/quality/character of patches to cherry-pick,
and the reasonably competent developers are not interested in stable
release work.

Any option I forgot here?

-- 
David Kastrup