Open Stack

On 21 January 2016 at 07:38, Ian Cordasco <ian.cordasco at rackspace.com> wrote:
>
> I think this is a solid proposal but I'm not sure what (if anything) the TC needs to do about this. This is something most non-corporate open source projects do (and even some corporate open source projects). It's the natural life-cycle of any software project (that we ship a bunch of things and then focus on stability). Granted, I haven't seen much of a focus on it in OpenStack but that's a different story.
>
> That said, I'd like to see a different release cadence for cycles that are "stabilization cycles". We, as a community, are not using minor version numbers. During a stabilization cycle, I would like to see master be released around the 3 milestones as X.1.0, X.2.0, X.3.0. If we work that way, then we'll be able to avoid having to backport a lot of work to the X.0 series and while we could support X.0 series with specific backports, it would avoid stressing our already small stable teams. My release strategy, however, may cause more stress for downstream packages though. It'll cause them to have to decide what and when to package and to be far more aware of each project's current development cycle. I'm not sure that's positive.

So the reason this was on my todo this cycle - and I'm so glad Flavio
has picked it up (point 9 of
https://rbtcollins.wordpress.com/2015/11/02/openstack-mitaka-debrief/)
- was that during the Tokyo summit, in multiple sessions, folk were
saying that they wanted space from features, to consolidate already
added things, and to cleanup accrued debt, and that without TC
support, they couldn't sell it back to their companies.

Essentially, if the TC provides some leadership here: maybe as little as:
 - its ok to do it [we think it will benefit our users]
 - sets some basic expectations

And then individual projects decide to do it (whether thats a PTL
call, a vote, core consensus, whatever) - then developers have a
platform to say to their organisation that the focus is X, don't
expect features to land - and that they are *expected* to help with
the cycle.

Without some framework, we're leaving those developers out in the cold
trying to explain what-and-why-and-how all by themselves.

-Rob


-- 
Robert Collins <rbtcollins at hpe.com>
Distinguished Technologist
HP Converged Cloud