Re: Release process for 2.18 cancelled

[Trevor Daniels]

David Kastrup wrote Monday, March 18, 2013 11:14 AM


> "Trevor Daniels" <address@hidden> writes:
> 
>> David Kastrup Monday, March 18, 2013 8:52 AM
>>> 
>>> It turns out that the pent-up pressure to get forward-looking changes
>>> into the master branch that have transitory user interfaces or extensive
>>> changes of internals not exposed to sufficient testing is already too
>>> high to permit a prerelease phase focused on arriving at stable release
>>> quality.
>>> 
>>> So a release process of 2.18 managed by me is off.  In the current
>>> situation, I don't consider it realistic that we will be able to make a
>>> stable release with sufficient reliability in the next four months at
>>> least, likely longer.
>>
>> It's a pity, but I think you're right.  But during that four months or
>> longer we need to be vigilant to prevent any potentially disruptive
>> changes entering master.  Encouraging or requiring developers to use
>> branches for anything other than tidying up or bugfixes from now
>> onwards seems desirable to me.
> 
> The way to do that is to bind people to their predictions of what can
> and cannot be achieved in a certain amount of time by agreeing on a
> timeline in advance and putting in deadlines for certain kinds of
> changes.

This looks a promising approach.  Suppose we ask developers to set
out what new features they would like to complete in time for a 2.18
release, together with their estimate of the date by which they would be
implemented.  Not bug-free, but steered through review and pushed in
a working state.  The date would be firm, with the implication that if
it were not met the feature would automatically slip into 2.19.

We could then review the list, vote as a community on the features
to be implemented in 2.18, and set a time for the release (obviously
some weeks after the last feature date.)  Any feature not in the agreed
list would not be accepted for 2.18, and clearly a long estimated 
implementation  date for any feature might be enough to rule it out.

> That means agreeing on a policy in advance rather than making decisions
> on the fly, based on the best currently available information.

Would the above be a start on a policy?  At least it would guarantee
2.18 would eventually be released.  We'd need to define 'feature', of
course.

Trevor