Re: Release process for 2.18 cancelled

[David Kastrup]

"Trevor Daniels" <address@hidden> writes:

> David Kastrup wrote Monday, March 18, 2013 11:14 AM
>
>> 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?

Not really.

> At least it would guarantee 2.18 would eventually be released.  We'd
> need to define 'feature', of course.

The current standoff is not about which feature should be desirable or
not, but rather what kind of change should be permitted into a stable
release.  A "feature" consists of functionality, programming APIs and
user interfaces.  Without well-fitting user interfaces, the
functionality will not see a reasonable amount of testing and it will
not be possible to make a good-faith effort to making that feature
remain accessible in the same manner for more than one release.

So it is pointless on focusing on a particular set of features for the
release planning.  In particular since this will severely disadvantage
those programmers with conservative estimates about their work.

Instead we need to set deadlines for the state any functionality may be
in for the sake of being admitted into master.  The first lockdown date
will likely be for features of the "dump code now, think about user
interface later" variety.  They will need to be in a well-confined state
where it is possible to just revert them in the stable branch if it
turns out that the "think about user interface later" angle will not be
satisfactorily addressed until the release.  Similarly there will be a
deadline for changes of the "this does not affect the actual current
feature set, has large repercussions on code stability, but might come
in handy some time in future" kind.

We'll set up deadlines for various kinds of changes, and when they are
voted to belong in a particular category, that means that after they
passed the deadline, they will not pass into master.  It does not
preclude them being worked on in a separate feature branch.

-- 
David Kastrup