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)