Hi Jay,
On Tue, Nov 1, 2022 at 8:17 PM Jay Faulkner jay@gr-oss.io wrote:
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'd like to see the errors. We update Zuul configuration manually for each bugfix branch, mapping appropriate branches for other projects (devstack, nova, etc). It's possible that we always overlook a few jobs, which causes Zuul to be upset (but quietly upset, so we don't notice).
I've put together a document describing the situation as it is now, and my proposal: https://etherpad.opendev.org/p/IronicBugfixBranchCleanup
Going with the "I would like to retire" would cause us so much trouble that we'll have to urgently create a downstream mirror of them. Once we do this, using upstream bugfix branches at all will be questionable. Especially bugfix/19.0 (and corresponding IPA/inspector branches) is used in a very actively maintained release.
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:
- 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).
EOL tags will be created by the release team, yes. I don't think we can get the keys without going "independent".
- 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.
With my vendor's (red) hat on, I'd prefer to have a dual approach: the newest branches are supported by the community (i.e. us all), the oldest - by vendors who need them (EOLed if nobody volunteers). I think you already have a list of branches that OCP uses? Feel free to point Riccardo, Iury or myself at any issues with them.
Dmitry
What do folks think?
Jay Faulkner