Re: Freezing for 2.18

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Mon, Mar 11, 2013 at 03:37:30PM +0100, David Kastrup wrote:
>> Colin Hall <address@hidden> 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