Open Stack

> 1) We have less review bandwidth even for active stable branches (Yoga, Zed and 2023.1)
> 2) No one, apart from the project team, does backport of critical fixes implying that those branches aren't used much for collaboration
> 3) Will save gate resources for some periodic jobs and the patches proposed
> 4) Save project team's time to fix gate issues

These are all good reasons, and I think that they highlight how the original plan for EM has turned out to have failed in practice. I think in most cases, it's the project teams that continue maintaining these, backporting patches here, and fixing zuul config issues or other gate fails when they happen. I myself tried to make the point recently that we should be dropping (not fixing) the ceph job on the wallaby gate when it broke (per the plan), but the well-meaning people involved ended up fixing it anyway. I think we're probably due to revisit the current EM strategy soon.

The recent CVE is the most important thing to me though. Anyone that looks at the recent activity in say, wallaby will see a lot of familiar faces and recent backports from the project teams. It would not be a stretch at all to assume that since we've backported minor fixes that we've also already backported the most substantial CVE in the last decade as well -- but we haven't (and won't). Nova is in a similar boat, with the last *two* CVEs unfixed in the earlier branches because of the complexity of the multiple projects, libraries, releases, and tests that need to be coordinated in order to have the desired effect. IMHO, it is the prudent and responsible thing to do to drop these branches which look maintained but in reality have known severe vulnerabilities in them.

> We, as the cinder team, have decided to EOL all the existing EM branches that go from Train to Xena. It was agreed upon by the cinder team and no objections were raised during the upstream cinder meeting.

Given the severity of the impact to older unpatched Cinder branches, think this makes sense. Nova isn't in quite the same boat, but I made the same arguments in this patch proposing to EOL train, where the second-to-last VMDK-related vulnerability remains unfixed:

https://review.opendev.org/c/openstack/releases/+/885365

--Dan