Open Stack

Hey,

This is actually not an uncommon misconception. The TC just passed new
policy (
https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html
) to try and clarify it.

The way things were:
- Day 0: OpenStack release happens.
- 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)
- 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).

The way things are now, since that policy was updated:
(Disclaimer: the policy is written in the https link above; below is my
understanding of it, not the policy itself. Please read the policy.)
- Day 0: OpenStack release happens (code lives in stable/YYYY.N)
- 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)
- 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.

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.

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.

Hope this helps,
Jay Faulkner
Ironic PTL
TC Vice-Chair

On Thu, Aug 24, 2023 at 7:27 AM Thomas Goirand <thomas at goirand.fr> wrote:

> On 8/23/23 22:21, Jay Faulkner wrote:
> > Hi all,
> >
> > Ironic is one of the major offenders remaining in the work to cleanup
> > Zuul config errors. To resolve these issues, it's my plan to retire any
> > impacted branches unless a contributor volunteers to clean them up. I
> > will give folks until at least September 1, 2023, to object before I
> > begin to take action.
>
> In fact, this makes me question how it works in OpenStack in general. It
> feels like many projects are doing their ways, and deprecating old
> branches in different ways. Sometimes, this happens when a CVE can't be
> addressed in a proper way.
>
> So I wonder: what's the promised lifecycle of a release, and why this is
> different depending on the project? Aren't we committed to maintain at
> last the latest 3 releases? If so, then deprecating any branch before
> Yoga is currently fine, no? If so, why are projects keeping stable
> branches opened for longer?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230824/13019e09/attachment.htm>