<div dir="ltr"><div dir="ltr">Hey,<br></div><div dir="ltr"><div><br></div><div>This is actually not an uncommon misconception. The TC just passed new policy ( <a href="https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html">https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html</a> ) to try and clarify it.</div><div><br></div><div>The way things were:</div><div>- Day 0: OpenStack release happens.</div><div>- Month 18: OpenStack release is no longer maintained, is moved into Extended Maintenance (this historically meant a lower level of support and no releases cut) </div><div>- At each individual project's leisure, keeping in mind dependencies, they can retire the EM branch at any moment. Obviously, for projects like nova, keystone, or devstack with large dependency lists, there's a huge amount of community pressure to keep them open as long as possible. (This is why there was controversy when Cinder wanted to close their EM branches; it would potentially force projects depending on it to also close their branches).</div><div><br></div><div>The way things are now, since that policy was updated:</div><div>(Disclaimer: the policy is written in the https link above; below is my understanding of it, not the policy itself. Please read the policy.)</div><div>- Day 0: OpenStack release happens (code lives in stable/YYYY.N)</div><div>- Month 18: OpenStack release is no longer maintained. If it is a SLURP release, it is moved to unmaintained/ status automatically. (code is moved to unmaintained/YYYY.N)</div><div>- Months 30, 42, ...: Each year thereafter when a new SLURP release is cut, a project must evaluate if they wish to continue keeping this older unmaintained branch open. This is explicitly opt-in and requires that branch/project combo have passing CI.</div></div><div><br></div><div>One key problem with the old way: because branches were opened automatically, even projects that didn't have maintainers or users for an old stable branch would have them. That leads to cases like the zuul-config-errors, where CI for a branch is so neglected that it's causing higher level failures that are seen by OpenDev sysadmins.</div><div><br></div><div>So with these Ironic changes; IMO you should take them as the Ironic team being honest and open about what branches we're actually maintaining -- when I take the proposed action we won't be dropping support for anything so much as admitting we haven't supported them for months already. Hopefully the recently-landed items to both change the name to "unmaintained" to reflect it's actual status as an old release with minimal maintenance and the opt-in barrier to reduce the incidences of branches dying a slow death without users knowing they are no longer in development.</div><div><br></div><div>Hope this helps,</div><div>Jay Faulkner</div><div>Ironic PTL</div><div>TC Vice-Chair</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 24, 2023 at 7:27 AM Thomas Goirand <<a href="mailto:thomas@goirand.fr">thomas@goirand.fr</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 8/23/23 22:21, Jay Faulkner wrote:<br>
> Hi all,<br>
> <br>
> Ironic is one of the major offenders remaining in the work to cleanup <br>
> Zuul config errors. To resolve these issues, it's my plan to retire any <br>
> impacted branches unless a contributor volunteers to clean them up. I <br>
> will give folks until at least September 1, 2023, to object before I <br>
> begin to take action.<br>
<br>
In fact, this makes me question how it works in OpenStack in general. It <br>
feels like many projects are doing their ways, and deprecating old <br>
branches in different ways. Sometimes, this happens when a CVE can't be <br>
addressed in a proper way.<br>
<br>
So I wonder: what's the promised lifecycle of a release, and why this is <br>
different depending on the project? Aren't we committed to maintain at <br>
last the latest 3 releases? If so, then deprecating any branch before <br>
Yoga is currently fine, no? If so, why are projects keeping stable <br>
branches opened for longer?<br>
<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br></blockquote></div></div>