Open Stack

Hi Jay,

On Tue, Nov 1, 2022 at 8:17 PM Jay Faulkner <jay at 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:
> 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).
>

EOL tags will be created by the release team, yes. I don't think we can get
the keys without going "independent".


>
> 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.
>

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
>


-- 

Red Hat GmbH <https://www.redhat.com/de/global/dach>, Registered seat:
Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany
Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,Managing
Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20221102/9f281736/attachment.htm>