Open Stack

On 2020-06-10 11:46, Thierry Carrez 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 ?
> 
> 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'll check with the release team where that requirement came from, and 
> if we can safely relax it.

That would be great to have. Currently our RC1 is in no-touch state as 
it is broken by design (TM) and we always need to have RC2. :/

To summarize: nowadays we break our master branch to "release" 
half-broken RC1 to get a stable branch. Then we revert things on master 
to unbreak and work on stabilizing for release.

-yoctozepto