Open Stack

Donny Davis wrote:
> So when you say largely ignored, do you mean by downstream vendors who 
> package Openstack or by public clouds who use it daily?
> I can see a longer release cycle being better for vendors so they don't 
> have to do FFU to begin with and public clouds wanting faster releases 
> so they can get features to customers sooner.

The release cycle length discussion has happened roughly every 8 months 
for the last 9 years, and I don't think the reality has changed.

Longer release cycles does not facilitate merging features, nor does it 
spread the load. Evidence would rather point to the opposite 
(twice-bigger crunch at the end of the larger cycle).

Release cycle length actually affects three things.

1- with longer cycles, boilerplate tasks around releasing happen less 
often. This is largely a non-issue now that most of the release process 
is automated.

2- with longer cycles, the feedback loop between when a feature is 
written and when it's actually in use by users is getting longer. This 
is bad as the person who writes the feature in the first place may have 
moved to other things by the time the initial user feedback comes.

3- with longer cycles, there is less pressure on downstream to integrate 
the new release in their products. This remains true, even if we now 
have multiple options to skip irrelevant releases in products.

The current 6-month cycle is a trade-off, essentially a balance between 
(2) and (3). It is as long as we think we can stretch the cycle duration 
without ruining the feedback loop.

Obviously nobody is happy with it, with some wanting it to be longer, 
and some wanting it to be shorter. Which means that it is probably a 
good middle ground :)

-- 
Thierry Carrez (ttx)