Open Stack

The release management team discussed this topic at the meeting yesterday.

The current process works well in the case where you *know" you will 
only do one release (release-once), or you *know* you will do more than 
one release (release-often). We agree that it does not handle well the 
case where you actually have no idea how many releases you will do 
(release-if-needed).

We need to add a bit of flexibility there, but:

- the release team still needs to use a very limited number of standard 
release models, and know as much as possible in advance. We handle 
hundreds of OpenStack deliverables, we can't have everyone use their own 
release variant.

-  we don't want to disconnect project teams from their releases (we 
still want teams to trigger release points and feel responsible for the 
resulting artifact).

Here is the proposal we came up with:

- The general idea is, by milestone-2, you should have picked your 
release model. If you plan to release-once, you should use the 
cycle-with-rcs model. If you plan to release-often, you should be 
cycle-with-intermediary. In the hopefully rare case where you have no 
idea and would like to release-if-needed, continue to read.

- Between milestone-2 and milestone-3, we look up 
cycle-with-intermediary things that have not done a release yet. For 
those, we propose a switch to cycle-with-rcs, and use that to start a 
discussion.

At that point four things can happen:

(1) you realize you could do an intermediary release, and do one now. 
Patch to change release model is abandoned.

(2) you realize you only want to do one release this cycle, and +1 the 
patch.

(3) you still have no idea where you're going for this deliverable this 
cycle and would like to release as-needed: you -1 the patch. You 
obviously commit to producing a release before RC1 freeze. If by RC1 
freeze we still have no release, we'll force one.

(4) you realize that the deliverable should be abandoned, or should be 
disconnected from the "OpenStack" release and be made independent, or 
some other solution. You -1 the patch and propose an alternative.

In all cases that initial patch is the occasion to raise the discussion 
and cover that blind spot, well in advance of the final weeks of the 
release where we don't have time to handle differently each of our 
hundreds of deliverables.

Dmitry Tantsur wrote:
> Have you considered allowing intermediary releases with cycle-with-rc? 
> Essentially combining the two models into one?

You really only have two different scenarios.

A- the final release is more usable and important than the others
B- the final release is just another release, just happens to have a 
stable branch cut from it

In scenario (A), you use RCs to apply more care and make sure the one 
and only release works well. You can totally do other "releases" during 
the cycle, but since those are not using RCs and are not as carefully 
vetted, they use "beta" numbering.

In scenario (B), all releases are equally important and usable. There is 
no reason to use RCs for one and not the others.

-- 
Thierry Carrez (ttx)