I'm going to completely remove any logistical concerns from this reply; I'm going to assume it's possible because I don't think we should do it in any case. On 8/21/25 8:05 AM, Thomas Goirand wrote:
Hi,
It's our policy that we maintain only a few branches, currently, from Caracal to Epoxy (so, 3 stable branches).
Currently, when a Stable branch becomes unsuported, we rename that branch as:
unmaintained/2023.1
which is fine, as we can still commit there. Though after some times, the branches are deleted, and instead, we just do a tag such as:
zed-EOL
This is a good, positive signal to our customers, and their bosses, that it's not appropriate to run these versions anymore. I personally know of multiple clusters where 'but the branch is still open' was used as a justification to not-upgrade. I have no interest in enabling these use cases because I think it's actively harmful to the OpenStack ecosystem for people to be on dramatically old releases. I'll note this opinion is strongly influenced by the fact I work on a portion of OpenStack (Ironic) for which new releases are not just adding features, but adding and improving hardware support. Keeping these branches open, even with unmaintained/ terminology, at a certain point tells people that other folks are using years-old OpenStack, and that maybe it's OK for them to as well. I don't want to send this message.
Jeremy Stanley just wrote to me on IRC:
"workflows, processes and policies are built around many years of an assumption that unused branches will be deleted"
Keeping unmaintained branches "has put a lot of additional strain on project maintainers and our systems" (still quoting Jeremy).
Though each time there's a new (grave?) security problem, this topic comes back, as we still have no solution for these cases. As a downstream, I still need to write backports for these important patches, sometimes long after the branches are EOL. Red Hat too...
There have been multiple OSSAs over the last two years. I've done an (admittedly quick) review of the bugs associated with those OSSAs -- you were the only one requesting or mentioning support for EOL releases in those bugs. I know you may represent multiple downstream Debian customers; but I don't agree that this is a recurring major issue in the community. I'll also note that on those bugs, if someone wanted to provide older patches they could attach them there. Given the low-occurrence of CVE-worthy vulnerabilities (6 since the start of 2024), I do not think the convenience of an in-openstack-namespace branch is worth the tradeoffs I have mentioned above.
While I agree with all what Jeremy told me on IRC, and I don't think we should attempt to maintain the CI for too long (as this takes too much of our time), I still believe we should keep a way to share patches. Downstream (like myself for Debian) run their own CI based on packages, and it's always better if we can share patches. It doesn't have to be with a maintained CI. Just having opened branches would be enough.
There's no need for official OpenStack project cooperation to do that. You could store patches in a repo hosted elsewhere, or even have a forked-version of that branch which can be used for a Debian upstream (and other distributors who may be invested in ancient OpenStack versions). I agree cooperation is valuable, but contributor time is valuable and is short supply as well. I-personally am not motivated to spend that limited time giving users an additional excuse to delay their upgrade. -JayF P.S. I fear this came off more harshly than intended; I appreciate the work folks do in projects like Debian to give people a stable base to build on; I just do think that approach is not one we should extend further than we already do as an OpenStack upstream.