<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 9 Jun 2020, 11:01 Thierry Carrez, <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
As you know[1] I'm trying to push toward simplification of OpenStack <br>
processes, to make them easier to navigate for new members of our <br>
community and generally remove weight. A good example of that is release <br>
models.<br>
<br>
We used to have a single model (with milestones and RCs) but over time <br>
we grew a number of alternative models to accommodate corner cases. The <br>
result is a confusing collection of release models with abstract rules <br>
for each and not much flexibility. Projects are forced to choose between <br>
those models for their deliverables, with limited guidance. And much of <br>
the rationale for those models (exercise release machinery early and <br>
often, trigger external testing...) is no longer valid.<br>
<br>
I'd like to suggest we simplify this and have a single model for things <br>
that follow the development cycle: the "follows-cycle" model. The only <br>
alternative, its nemesis, its Wario would be the "independent" release <br>
model.<br>
<br>
In the "follows-cycle" model, deliverables would be released at least <br>
once per cycle, but could be released more often. The "final" release <br>
would be marked by creating a release (stable) branch, and that would <br>
need to be done before a deadline. Like today, that deadline depends on <br>
whether that deliverable is a library, a client library, a <br>
release-trailing exception or just a regular part of the common release.<br>
<br>
The main change this proposal introduces would be to stop having release <br>
candidates at the end of the cycle. Instead we would produce a release, <br>
which would be a candidate for inclusion in the coordinated OpenStack <br>
release. New releases could be pushed to the release branch to include <br>
late bugfixes or translation updates, until final release date. So <br>
instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 that gets promoted <br>
to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and just list that <br>
14.0.1 in the release page at coordinated release time.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I feel like this would not change that much for deliverables following <br>
the cycle-with-rc model. It would not change anything for <br>
cycle-with-intermediary, libraries or cycle-trailing deliverables. But <br>
it would simplify our processes quite a bit, and generally make our <br>
releases more consistent.<br>
<br>
Thoughts?<br>
<br>
[1] <br>
<a href="http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013236.html" rel="noreferrer noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013236.html</a><br>
<br>
-- <br>
Thierry Carrez (ttx)<br>
<br>
</blockquote></div></div></div>