Re: Freezing for 2.18

[address@hidden]

On 11 mars 2013, at 16:32, "Trevor Daniels" <address@hidden> wrote:

> 
> David Kastrup wrote Sunday, March 10, 2013 5:32 PM
> 
>> 2.16 is growing old.
>> 
>> So I want to see 2.18 soon.  That means we need to stabilize work that
>> has already been done and cut down on experiments in the master branch.
> 
> Agreed.
> 
>> Stabilizing means more or less accepting the current feature set, and
>> making sure it works as intended, is a useful combination of things,
>> does not offer interfaces which are sure not to survive into the next
>> stable version, and most of all, is properly documented to the user.
> 
> Once the decision to stabilise is taken, further work on new features
> should take place in branches.  It doesn't have to stop.  That's how the 
> skyline code was developed before it was merged into 2.17 and that 
> procedure worked well.
> 
>> At any rate, I'd like to aim for 2.18 at about the end of May, and
>> getting into serious freeze at the end of April.  A focus on bug fixes,
>> in particular bugs introduced in the 2.17 development cycle, should take
>> priority.  Fixing long-standing bugs hard to address should likely be
>> left for early 2.19 and/or be done in a branch.
> 
> Why not freeze sooner?  The current state is sufficiently different from
> 2.16 to justify a new stable.
> 
> I'd also like to propose we adopt the same controls as we did for 2.16,
> if David is willing, since that also worked well.  That way we'll get a
> clear plan - what must be fixed, what must be documented, what is
> permitted to go into master, etc.  Otherwise we'll simply disagree for
> ever.
> 

I like the idea of freezing right away and releasing after two weeks of 
critical-bug-free lily. What is difficult for me is setting the freeze down the 
line without being able to wrap up work first.

Cheers,
MS