Open Stack

On Fri, Aug 2, 2019 at 5:39 AM Thierry Carrez <thierry at openstack.org> wrote:

> 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.
>

This process seems reasonable, thanks Thierry! :)

// jim


>
> 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)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190802/a959c80c/attachment-0001.html>