<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 2, 2022 at 3:04 AM Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com">dtantsur@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Jay,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 1, 2022 at 8:17 PM Jay Faulkner <<a href="mailto:jay@gr-oss.io" target="_blank">jay@gr-oss.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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></blockquote><div><br></div><div>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).<br></div><div> </div></div></div></blockquote><div><br></div><div>The errors show up in <a href="https://zuul.opendev.org/t/openstack/config-errors">https://zuul.opendev.org/t/openstack/config-errors</a> -- although they seem to be broken this morning. Most of them are older bugfix branches, ones that are out of support, that have the `Queue: Ironic` param that's no longer supported. I am not in favor of anyone going to dead bugfix branches and fixing CI; instead we should retire the ones out of use.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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" target="_blank">https://etherpad.opendev.org/p/IronicBugfixBranchCleanup</a></div></div></blockquote><div><br></div><div>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.<br></div><div> </div></div></div></blockquote><div><br></div><div>Then we won't; but we do need to think about what timeline we can talk about upstream for getting a cadence for getting these retired out, just like we have a cadence for getting them cut every two months. I'll revise the list and remove the "I would like to retire" section (move it to keep-em-up).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>EOL tags will be created by the release team, yes. I don't think we can get the keys without going "independent".<br></div><div> </div></div></div></blockquote><div><br></div><div>It's a gerrit ACL you can enable to give other people access to tags; but like I said, I don't want that access anyway :).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>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.</div><div><br></div></div></div></blockquote><div><br></div><div>That's not really an option IMO. These branches exist in the upstream community, and are seen by upstream contributors and operators. If they're going to live here; they need to have some reasonable documentation about what folks should expect out of them and efforts being put towards them. Even if the documentation is "bugfix/1.2 is maintained as long as Product A 1.2 is maintained", that's better than leaving the community guessing about what these are used for, and why some are more-supported than others.</div><div><br></div><div>-Jay<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>Dmitry<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div><div>What do folks think?</div><div><br></div><div>- <br></div><div>Jay Faulkner<br></div></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><pre cols="72" style="white-space:pre-wrap"><a href="https://www.redhat.com/de/global/dach" target="_blank">Red Hat GmbH</a>, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany  
Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,
<span>Managing</span> Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross</pre></div></div></div>
</blockquote></div></div>