Open Stack

On Wed, Oct 5, 2022 at 7:18 AM Thierry Carrez <thierry at openinfra.dev> wrote:

> Clark Boylan wrote:
> > [...]
> > If the release team ends up doing the work, it would probably be a good
> idea to very explicitly list the branch, commit sha1, and version number
> for each of the needed releases. This way the release team doesn't have to
> guess if they are getting it correct when they make and push those tags.
>
> Yes please.
>
>
I'm cleaning up some CI right now; I'll make sure we get this information
to the list soon so we can give it a shot :).


> > Separately, it seems like some of the intention here is to ensure that
> users of bugfix branches don't end up with stale installations. Updating
> the release tooling to handle releases off of these branches or delegating
> access to the Ironic team seem like an important piece of making that
> happen. Otherwise the overhead for doing this will be large enough that it
> is unlikely to happen often enough. Unfortunately, I don't know what is
> currently missing in the tooling to make that possible.
>
> I'd say it's an unknown and the current release team members may not
> have bandwidth to explore what releasing on bugfix branches using a
> patch to openstack/releases could look like. Avoiding collisions between
> "normal" stable branch point updates and those bugfix branch point
> releases sounds tricky at best.
>
>
I'm hoping this won't be an issue. Ironic policy (and it seems to be true
in practice), says any release from master (including bugfix/x branches)
must bump either the major or minor release number (
https://specs.openstack.org/openstack/ironic-specs/specs/15.1/new-release-model.html#releasing
).


Thanks Thierry and Clark, I'll get you the information you all need to move
forward soon!

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