[ironic][release] Bugfix branch status and cleanup w/r/t zuul-config-errors

Jay Faulkner jay at gr-oss.io
Tue Nov 1 19:12:02 UTC 2022


Hey all,

I've been looking into the various zuul config errors showing up for
Ironic-program branches. Almost all of our old bugfix branches are in the
list. Additionally, not properly retiring the bugfix branches leads to an
ever-growing list of branches which makes it a lot more difficult, for
contributors and operators alike, to tell which ones are currently
supported.

I've put together a document describing the situation as it is now, and my
proposal:
https://etherpad.opendev.org/p/IronicBugfixBranchCleanup

Essentially, I think we need to:
- identify bugfix branches to cleanup (I've done this in the above
etherpad, but some of the )
- clean them up (the next step)
- update Ironic policy to set a regular cadence for when to retire bugfix
branches, and encode the process for doing so

This means there are two overall questions to answer in this email:
1) Mechanically, what's the process for doing this? I don't believe the
existing release tooling will be useful for this, but I'm not 100% sure.
I've pulled (in the above etherpad and a local spreadsheet) the last SHA
for each branch; so we should be able to EOL these branches similarly to
how we EOL stable branches; except manually instead of with tooling. Who is
going to do this work? (I'd prefer releases team continue to hold the keys
to do this; but I understand if you don't want to take on this manual work).

2) What's the pattern for Ironic to adopt regarding these branches? We just
need to write down the expected lifecycle and enforce it -- so we prevent
being this deep into "branch debt" in the future.


What do folks think?

-
Jay Faulkner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20221101/fb45010b/attachment.htm>


More information about the openstack-discuss mailing list