<div dir="ltr"><div>Hey all,</div><div><br></div><div>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.</div><div><br></div><div>I've put together a document describing the situation as it is now, and my proposal:</div><div><a href="https://etherpad.opendev.org/p/IronicBugfixBranchCleanup">https://etherpad.opendev.org/p/IronicBugfixBranchCleanup</a></div><div><br></div><div>Essentially, I think we need to:</div><div>- identify bugfix branches to cleanup (I've done this in the above etherpad, but some of the )</div><div>- clean them up (the next step)<br></div><div>- update Ironic policy to set a regular cadence for when to retire bugfix branches, and encode the process for doing so</div><div><br></div><div>This means there are two overall questions to answer in this email:</div><div>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).</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>What do folks think?</div><div><br></div><div>- <br></div><div>Jay Faulkner<br></div></div>