2.14 release, or GOP now (part 2)

[Graham Percival]

A brief reminder of the timeline:
- 18 Sep 2010: "we need to sort out various policies, but let's
  wait until 2.14"
http://lists.gnu.org/archive/html/lilypond-devel/2010-09/msg00178.html
- 22 Sep 2010: "alpha test 1 for 2.14, only 1 critical issue"
http://lists.gnu.org/archive/html/info-lilypond/2010-09/msg00002.html
- 24 Oct 2010: "estimated 10-20 hours to finish critical issues,
  but maybe we should start the policy stuff now"
http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00404.html
- now (29 Nov 2010): 6 critical issues, and I'm aware of another
  2 which haven't been added, estimated 50 hours of work.  Lots of
  good work done in the past month; some on critical problems
  which were discovered since Oct, and some on non-critical
  problems.

In short, it seems that the number of open critical issues is a
poor predictor of the amount of work left.  At the current rate of
development and bug-finding, I would be surprised if we have a
stable release before February 2011.

With that in mind, I'm reopening the same question as the 24 Oct
email.  We've been "just a few more weeks" away from a release
since August.  I've been actively discouraging any policy
discussion which wasn't absolutely time-sensitive.  I've been
foisting off new contributors with a minimum of care and attention
to save time for release-oriented tasks.  If we were honestly
"just 2 or 3 more weeks" away from a release, then this would make
sense.  But since we're not, I'm not certain that it does.

I see five main possibilities:
1) release stable 2.14 ASAP with criticial flaws.
  I do not like this idea; it makes a mockery of the words "stable",
  "critical", or both.  Any Criticical issue in our tracker is
  Critical for good reasons.  I'm open to having a discussion about
  those reasons, and changing the priority if appropriate (for
  example, if we discover that a bug is not actually a regression).
  But as long as we officially acknowledge a flaw as Critical, in my
  mind this should absolutely prohibit a "stable" release.

2) release 2.14 ASAP with no critical flaws, but with some kind of
code freeze.
  Many software projects implement a "freeze" before a release --
  when the project is "frozen", this means that no changes are
  allowed, unless they have a very good reason why they absolutely
  must be changed before the next release.  With git, there's no
  technical reason why we might want to freeze anything (I could
  just branch a stable/2.14, and just cherry-pick individual commits
  to apply to this branch).  However, there are social reasons for a
  freeze.  We (implicitly) have a freeze on policy decisions, to
  avoid spending time on those instead of release-critical work.
  We could add a freeze on patches and code, to avoid spending
  time on those instead of release-critical work.

  I do not like this idea either.  This is a volunteer project;
  telling contributors that we will (for example) not discuss any
  changes to tabulature code is not going to encourage those
  volunteers to stick around.

3) continue development as we do now.
  We have a "freeze" on policy decisions, but not code.  Expected
  release is Feb - March 2011.  I am personally fed up with
  critical bugs, so I would spend a bit more time helping new
  contributors, but I would not raise any policy questions.  We
  make no particular attempt to focus development on
  release-critical issues.

  I am aware that there is some dissatisfaction with the current
  state of affairs.  I am neutral on this point.

4) begin part of GOP now.
  We begin policy discussions, and spend time to make sure that
  new contributors know what they're doing and can work
  effectively.  This is estimated to take about 200 hours of
  developer time.  Expected release for 2.14 is summer 2011.  We
  officially tell users that the "release countdown" has ended.
  If we ever get down to 0 critical issues, we'll release 2.14, of
  course, but this most likely would not happen for months and
  months.

  I have a slight preference for this option.  I am aware that
  telling users "whoops, sorry, cancel all those beta and alpha
  tests" will make us look a bit silly, but oh well.

5) begin all of GOP and GLISS.
  We begin policy discussions.  We begin actively recruiting new
  contributors.  We begin discussing syntax changes.  Expected
  release of 2.14 is in 2012.

  I do not like this option.


What do you think?  This is not a vote, but I would like to hear
from people.  I am hoping that we can find a reasonable amount of
consensus.

Cheers,
- Graham