Open Stack

On Wed, 10 Jun 2020 at 10:47, Thierry Carrez <thierry at openstack.org> wrote:
>
> Mark Goddard wrote:
> > [...]
> > One substantial change here is that there will no longer be a period
> > where the stable branch exists but the coordinated release does not.
> > This could be an issue for cycle trailing projects such as kolla which
> > sometimes get blocked on external (and internal) factors. Currently we
> > are able to revert master from it's temporary stable mode to start
> > development for the next cycle, while we continue stabilising the stable
> > branch for release.
>
> Making sure I understand... Currently you are using RC1 to create the
> stable branch, but it's not really a "release candidate", it's more a
> starting point for stabilization ? So you can have a broken master
> branch, tag it RC1 and create stable/ussuri from it, then work on making
> stable/ussuri releasable while keeping master broken ?

That's right. It's more incomplete than broken though. For example,
RDO depends on Kolla's RC1 for it's GA, then we update the stable
branch to install the RDO release RPM when it becomes available.

There's also a slightly weird dance we have to do where we make master
'look like' the new release, by setting the branch name for our
dependencies etc, then we revert those changes on master after the
branch is cut. If the requirement to branch and RC1 at the same time
was lifted it would avoid the need for this.

>
> If I understand correctly, then it's a fair point: the new model
> actually makes release candidates real release candidates, so it does
> not really support having a master branch that never gets close to
> releasable state. I would argue that this was not really the intent
> before with RC1 tags, but it certainly made it easier to hide.
>
> To support your case more clearly, maybe we could allow creating stable
> branches from arbitrary commit SHAs. It used to be the case before (when
> stable branches were created by humans) but when automation took over we
> enforced that branches need to be created from tags.

I think that would work well for us.

>
> I'll check with the release team where that requirement came from, and
> if we can safely relax it.
>
> --
> Thierry Carrez (ttx)
>