Open Stack

On Fri, 2016-01-22 at 13:54 +0100, Thierry Carrez wrote:
> Zane Bitter wrote:
> > [...] Honestly, it
> > sounds like the kind of thing you come up with when you've given
> > up.
> 
> I tend to agree with that... I think healthy projects should
> naturally 
> come up with bursts of feature addition and bursts of repaying
> technical 
> debt. That is why I prefer not to be too prescriptive here.
> 
> If some people are under the impression that pausing feature addition
> in 
> order to focus on stability is discouraged, we should fix that (and I
> think this thread is a great way of making it clearer). But I would
> be 
> reluctant to start standardizing what a "stabilization period" is, or
> starting to impose them. As a lot of people said, ideally you would
> add 
> features and repay technical debt continuously. Imposing specific 
> periods of stabilization prevents reaching that ideal state.
> 
> So in summary: yes to expressing that it is fine to have them, no to 
> being more prescriptive about them.

Experience with Linux shows that deliberate stabilisation cycles, where
you refuse to accept features simply don't work: everyone gets
frustrated and development suffers.  You get lots of features disguised
as bug fixes and a lot of fighting when you try to police the bug fixes
to extract the hidden features which saps effort.

I still think what OpenStack actually needs is simply a longer
stabilisation time.  Right now, in the 6 month cycle, there are about
five months of development beginning with the design summit and one
month of -rc stabilisation.  In today's model, to extend stabilisation
you have to steal time from feature development, which again causes a
lot of argument.  To fix this, I'd turn that around and make it one
month of feature merging followed by five months of -rc stabilisation. 
 Essentially following the merge window pattern that makes the Linux
Kernel work so well.

The behaviour changes that would have to happen would be that there
would need to be a next-openstack tree that features get landed in
which would be where stuff was pulled from during the merge window
provided they pass the usual continuous tests.  Probably the design
summit would have to be just after the end of the merge window (and the
beginning of the -rc cycle) to be effective at discussing all the new
features and any feature that failed to make it to the merge window
would get held off to the next release.  This gives an effective five
month window to land features for the next release plus a five month
stabilisation cycle while keeping a 6 month release cycle.  The cost
for doing this is largely borne by feature developers who have to plan
which merge window to aim for.

James