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