<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 5, 2021 at 5:04 PM Mohammed Naser <<a href="mailto:mnaser@vexxhost.com">mnaser@vexxhost.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Nov 5, 2021 at 10:39 AM Thierry Carrez <<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>> wrote:<br>
><br>
> Hi everyone,<br>
><br>
> The (long) document below reflects the current position of the release<br>
> management team on a popular question: should the OpenStack release<br>
> cadence be changed? Please note that we only address the release<br>
> management / stable branch management facet of the problem. There are<br>
> other dimensions to take into account (governance, feature deprecation,<br>
> supported distros...) to get a complete view of the debate.<br>
><br>
> Introduction<br>
> ------------<br>
><br>
> The subject of how often OpenStack should be released has been regularly<br>
> debated in the OpenStack community. OpenStack started with a 3-month<br>
> release cycle, then switched to 6-month release cycle starting with<br>
> Diablo. It is often thought of a release management decision, but it is<br>
> actually a much larger topic: a release cadence is a trade-off between<br>
> pressure to release more often and pressure to release less often,<br>
> coming in from a lot of different stakeholders. In OpenStack, it is<br>
> ultimately a Technical Committee decision. But that decision is informed<br>
> by the position of a number of stakeholders. This document gives<br>
> historical context and describes the current release management team<br>
> position.<br>
><br>
> The current trade-off<br>
> ---------------------<br>
><br>
> The main pressure to release more often is to make features available to<br>
> users faster. Developers get a faster feedback loop, hardware vendors<br>
> ensure software is compatible with their latest products, and users get<br>
> exciting new features. "Release early, release often" is a best practice<br>
> in our industry -- we should generally aim at releasing as often as<br>
> possible.<br>
><br>
> But that is counterbalanced by pressure to release less often. From a<br>
> development perspective, each release cycle comes with some process<br>
> overhead. On the integrators side, a new release means packaging and<br>
> validation work. On the users side, it means pressure to upgrade. To<br>
> justify that cost, there needs to be enough user-visible benefit (like<br>
> new features) in a given release.<br>
><br>
> For the last 10 years for OpenStack, that balance has been around six<br>
> months. Six months let us accumulate enough new development that it was<br>
> worth upgrading to / integrating the new version, while giving enough<br>
> time to actually do the work. It also aligned well with Foundation<br>
> events cadence, allowing to synchronize in-person developer meetings<br>
> date with start of cycles.<br>
><br>
> What changed<br>
> ------------<br>
><br>
> The major recent change affecting this trade-off is that the pace of new<br>
> development in OpenStack slowed down. The rhythm of changes was divided<br>
> by 3 between 2015 and 2021, reflecting that OpenStack is now a mature<br>
> and stable solution, where accessing the latest features is no longer a<br>
> major driver. That reduces some of the pressure for releasing more<br>
> often. At the same time, we have more users every day, with larger and<br>
> larger deployments, and keeping those clusters constantly up to date is<br>
> an operational challenge. That increases the pressure to release less<br>
> often. In essence, OpenStack is becoming much more like a LTS<br>
> distribution than a web browser -- something users like moving slow.<br>
><br>
> Over the past years, project teams also increasingly decoupled<br>
> individual components from the "coordinated release". More and more<br>
> components opted for an independent or intermediary-released model,<br>
> where they can put out releases in the middle of a cycle, making new<br>
> features available to their users. This increasingly opens up the<br>
> possibility of a longer "coordinated release" which would still allow<br>
> development teams to follow "release early, release often" best<br>
> practices. All that recent evolution means it is (again) time to<br>
> reconsider if the 6-month cadence is what serves our community best, and<br>
> in particular if a longer release cadence would not suit us better.<br>
><br>
> The release management team position on the debate<br>
> --------------------------------------------------<br>
><br>
> While releasing less often would definitely reduce the load on the<br>
> release management team, most of the team work being automated, we do<br>
> not think it should be a major factor in motivating the decision. We<br>
> should not adjust the cadence too often though, as there is a one-time<br>
> cost in switching our processes. In terms of impact, we expect that a<br>
> switch to a longer cycle will encourage more project teams to adopt a<br>
> "with-intermediary" release model (rather than the traditional "with-rc"<br>
> single release per cycle), which may lead to abandoning the latter,<br>
> hence simplifying our processes. Longer cycles might also discourage<br>
> people to commit to PTL or release liaison work. We'd probably need to<br>
> manage expectations there, and encourage more frequent switches (or<br>
> create alternate models).<br>
><br>
> If the decision is made to switch to a longer cycle, the release<br>
> management team recommends to switch to one year directly. That would<br>
> avoid changing it again anytime soon, and synchronizing on a calendar<br>
> year is much simpler to follow and communicate. We also recommend<br>
> announcing the change well in advance. We currently have an opportunity<br>
> of making the switch when we reach the end of the release naming<br>
> alphabet, which would also greatly simplify the communications around<br>
> the change.<br>
><br>
> Finally, it is worth mentioning the impact on the stable branch work.<br>
> Releasing less often would likely impact the number of stable branches<br>
> that we keep on maintaining, so that we do not go too much in the past<br>
> (and hit unmaintained distributions or long-gone dependencies). We<br>
> currently maintain releases for 18 months before they switch to extended<br>
> maintenance, which results in between 3 and 4 releases being maintained<br>
> at the same time. We'd recommend switching to maintaining one-year<br>
> releases for 24 months, which would result in between 2 and 3 releases<br>
> being maintained at the same time. Such a change would lead to longer<br>
> maintenance for our users while reducing backporting work for our<br>
> developers.<br>
><br>
<br>
Thanks for the write up Thierry.<br></blockquote><div><br></div><div>++ very well written!<br></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>
I wonder what are the thoughts of the community of having LTS + normal releases<br>
so that we can have the power of both?  I guess that is essentially what we have<br>
with EM, but I guess we could introduce a way to ensure that operators can just<br>
upgrade LTS to LTS.<br></blockquote><div><br></div><div>This is basically what Ironic does: we release with the rest of OpenStack, but we also do 2 more releases per cycle with their own bugfix/X.Y branches.</div><div><br></div><div>Dmitry<br></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>
It can complicate things a bit from a CI and project management side,<br>
but I think it<br>
could solve the problem for both sides that need want new features +<br>
those who want<br>
stability?<br>
<br>
> --<br>
> Thierry Carrez (ttx)<br>
> On behalf of the OpenStack Release Management team<br>
><br>
<br>
<br>
-- <br>
Mohammed Naser<br>
VEXXHOST, Inc.<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Red Hat GmbH, <a href="https://de.redhat.com/" target="_blank">https://de.redhat.com/</a> , Registered seat: Grasbrunn, <br>Commercial register: Amtsgericht Muenchen, HRB 153243,<br>Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill <br></div></div></div>