[cinder][all][tc][ops][stable] EOL EM branches

Jeremy Stanley fungi at yuggoth.org
Tue Jun 6 17:32:32 UTC 2023


On 2023-06-06 20:01:45 +0530 (+0530), Rajat Dhasmana wrote:
[...]
> The discussion started because of the CVE fixes where we
> backported to active stable branches i.e. Yoga, Zed and 2023.1 but
> there were no backports to further EM stable branches like Xena,
> Wallaby ... all the way to Train.
[...]

The idea behind EM branches was that downstream distributions who
need to backport these changes for their own customers would push
the patches to the upstream EM branches so that they didn't all have
to redo the same work and could benefit from each other's knowledge
and experience around backports. If that's not happening for
critical security patches, then I agree that the goal of the EM
model has failed.

Taking OSSA-2023-003 (CVE-2023-2088) as the most recent example,
the advisory and patches for maintained branches were published
four weeks ago. Fixes for stable/xena were developed along with the
other backports because the branch had only just transitioned to EM
a week or two prior. Of the four deliverables which were patched as
part of that advisory, only Nova provided a patch for anything
older, and that was just to stable/wallaby (and possibly added as a
mistake or due to miscommunication between the various groups
involved).

In the four weeks since, I haven't seen anyone outside the core
review teams for Cinder, Glance or Nova supply changes for
additional backports, even though I expect the downstream
distributions patched versions contemporary with some branches still
in EM. It could be that this vulnerability is a poor example,
because a lot of deployments use RBD by default and it wasn't
affected, but the situation with the two other advisories earlier in
the year wasn't much different where backports were concerned.

> 1) We have less review bandwidth even for active stable branches
> (Yoga, Zed and 2023.1)

The intent for EM was that reviewing branches no longer under normal
maintenance could be delegated to other members of the community. Of
course, that was the idea with stable maintenance as well. Perhaps
it would be more accurate to restate this as there are no volunteers
to review the changes (it shouldn't be the core review team's
obligation either way)?

> 2) No one, apart from the project team, does backport of critical
> fixes implying that those branches aren't used much for
> collaboration

This is the best rationale for scrapping the whole EM idea, in my
opinion. There's a possibility that if the core reviewers weren't
pushing backports someone else would have done so eventually, but I
think we have plenty of evidence now to indicate that doesn't really
happen in practice.

> 3) Will save gate resources for some periodic jobs and the patches
> proposed

EM branches don't have to run the same jobs as maintained stable
branches (or really any jobs at all), but that does still at a
minimum need the attention of someone interested in removing the
unwanted jobs.

> 4) Save project team's time to fix gate issues
[...]

Similar to the earlier points, the project team shouldn't feel
obligated to fix testing issues on EM branches. If testing breaks,
it should be up to the volunteers proposing and reviewing changes to
do that. If they don't, nothing will merge. If they don't care
enough to keep it possible to merge things, then sure that's
basically back to item #1 again.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230606/e4729592/attachment.sig>


More information about the openstack-discuss mailing list