Graham Percival <gra...@percival-music.ca> writes: > On Mon, Mar 11, 2013 at 03:37:30PM +0100, David Kastrup wrote: >> Colin Hall <colingh...@gmail.com> writes: >> >> > Absolutely. I thought that we had adopted this proposal: >> > >> > http://lilypond.org/~graham/gop/gop_3.html >> >> So what? >> >> 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. >> >> For one thing, we are not talking about 2.16. For another, the deadline >> has passed. > > I'm comfortable adopting a similar policy: > > David Kastrup has sole authority over what goes into stable/2.18 > and which release(s) will have a version number of 2.18.x, until > 2013 Dec 31.
Well, I missed the time frame for having a proper proposal and voting/objection period. And we have not yet split off a branch, anyway. As we have a few patches relevant to whether a timely 2.18 release is realistic, I'd ask for a tentative delay for committing potentially destabilizing material until the split-off of the branch, to occur in about two weeks. If we agree to reasonable objections to this rather abrupt and non-voted freeze, it is open for dissolution. After the splitoff of the branch, moderation on master is still required: we don't want fundamental and/or badly mergeable (=extensive) changes to occur before 2.18 is released. Fundamental changes make it less likely that problems in stable/2.18 correspond to problems in master, so they make the stabilizing period less effective for detecting problems. After 2.18.0 is released, fundamental changes in master are ok again, but it makes sense to first release 2.19.0 with the accumulated changes that did not make it into 2.18, to have a reliable point of comparison for the fundamental changes. We will probably have time enough to properly decide about any dictatorial powers over stable/2.18, but to have this decision make any actual sense, it will require cooperation for the goals of releasing 2.18.0 on master as well. And I think that we reached a good point of time to start with that, or I foresee easily a few months of delay that are not necessarily in the best interest of our users, and that would also lead to increased tensions because of conflicting goals and interests. Getting the stable release out the door will hopefully get those out of the way for a while again. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel