<div dir="ltr"><div dir="ltr">On Fri, Aug 2, 2019 at 5:39 AM Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The release management team discussed this topic at the meeting yesterday.<br>
<br>
The current process works well in the case where you *know" you will <br>
only do one release (release-once), or you *know* you will do more than <br>
one release (release-often). We agree that it does not handle well the <br>
case where you actually have no idea how many releases you will do <br>
(release-if-needed).<br>
<br>
We need to add a bit of flexibility there, but:<br>
<br>
- the release team still needs to use a very limited number of standard <br>
release models, and know as much as possible in advance. We handle <br>
hundreds of OpenStack deliverables, we can't have everyone use their own <br>
release variant.<br>
<br>
-  we don't want to disconnect project teams from their releases (we <br>
still want teams to trigger release points and feel responsible for the <br>
resulting artifact).<br>
<br>
Here is the proposal we came up with:<br>
<br>
- The general idea is, by milestone-2, you should have picked your <br>
release model. If you plan to release-once, you should use the <br>
cycle-with-rcs model. If you plan to release-often, you should be <br>
cycle-with-intermediary. In the hopefully rare case where you have no <br>
idea and would like to release-if-needed, continue to read.<br>
<br>
- Between milestone-2 and milestone-3, we look up <br>
cycle-with-intermediary things that have not done a release yet. For <br>
those, we propose a switch to cycle-with-rcs, and use that to start a <br>
discussion.<br>
<br>
At that point four things can happen:<br>
<br>
(1) you realize you could do an intermediary release, and do one now. <br>
Patch to change release model is abandoned.<br>
<br>
(2) you realize you only want to do one release this cycle, and +1 the <br>
patch.<br>
<br>
(3) you still have no idea where you're going for this deliverable this <br>
cycle and would like to release as-needed: you -1 the patch. You <br>
obviously commit to producing a release before RC1 freeze. If by RC1 <br>
freeze we still have no release, we'll force one.<br>
<br>
(4) you realize that the deliverable should be abandoned, or should be <br>
disconnected from the "OpenStack" release and be made independent, or <br>
some other solution. You -1 the patch and propose an alternative.<br>
<br>
In all cases that initial patch is the occasion to raise the discussion <br>
and cover that blind spot, well in advance of the final weeks of the <br>
release where we don't have time to handle differently each of our <br>
hundreds of deliverables.<br></blockquote><div><br></div><div>This process seems reasonable, thanks Thierry! :)</div><div><br></div><div>// jim</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Dmitry Tantsur wrote:<br>
> Have you considered allowing intermediary releases with cycle-with-rc? <br>
> Essentially combining the two models into one?<br>
<br>
You really only have two different scenarios.<br>
<br>
A- the final release is more usable and important than the others<br>
B- the final release is just another release, just happens to have a <br>
stable branch cut from it<br>
<br>
In scenario (A), you use RCs to apply more care and make sure the one <br>
and only release works well. You can totally do other "releases" during <br>
the cycle, but since those are not using RCs and are not as carefully <br>
vetted, they use "beta" numbering.<br>
<br>
In scenario (B), all releases are equally important and usable. There is <br>
no reason to use RCs for one and not the others.<br>
<br>
-- <br>
Thierry Carrez (ttx)<br>
<br>
</blockquote></div></div>