Open Stack

On Tue, 9 Jun 2020, 11:01 Thierry Carrez, <thierry at openstack.org> wrote:

> Hi everyone,
>
> As you know[1] I'm trying to push toward simplification of OpenStack
> processes, to make them easier to navigate for new members of our
> community and generally remove weight. A good example of that is release
> models.
>
> We used to have a single model (with milestones and RCs) but over time
> we grew a number of alternative models to accommodate corner cases. The
> result is a confusing collection of release models with abstract rules
> for each and not much flexibility. Projects are forced to choose between
> those models for their deliverables, with limited guidance. And much of
> the rationale for those models (exercise release machinery early and
> often, trigger external testing...) is no longer valid.
>
> I'd like to suggest we simplify this and have a single model for things
> that follow the development cycle: the "follows-cycle" model. The only
> alternative, its nemesis, its Wario would be the "independent" release
> model.
>
> In the "follows-cycle" model, deliverables would be released at least
> once per cycle, but could be released more often. The "final" release
> would be marked by creating a release (stable) branch, and that would
> need to be done before a deadline. Like today, that deadline depends on
> whether that deliverable is a library, a client library, a
> release-trailing exception or just a regular part of the common release.
>
> The main change this proposal introduces would be to stop having release
> candidates at the end of the cycle. Instead we would produce a release,
> which would be a candidate for inclusion in the coordinated OpenStack
> release. New releases could be pushed to the release branch to include
> late bugfixes or translation updates, until final release date. So
> instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 that gets promoted
> to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and just list that
> 14.0.1 in the release page at coordinated release time.
>

One substantial change here is that there will no longer be a period where
the stable branch exists but the coordinated release does not. This could
be an issue for cycle trailing projects such as kolla which sometimes get
blocked on external (and internal) factors. Currently we are able to revert
master from it's temporary stable mode to start development for the next
cycle, while we continue stabilising the stable branch for release.

We do intend to be more prompt about our releases, but there is always
something that comes up. We may end up having to choose between releasing
with known issues vs. halting development for the next cycle. On the other
hand, perhaps a little focus would help us to push it over the line faster.


> I feel like this would not change that much for deliverables following
> the cycle-with-rc model. It would not change anything for
> cycle-with-intermediary, libraries or cycle-trailing deliverables. But
> it would simplify our processes quite a bit, and generally make our
> releases more consistent.
>
> Thoughts?
>
> [1]
>
> http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013236.html
>
> --
> Thierry Carrez (ttx)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200609/7b35df0d/attachment.html>