[Development] Proposal: New branch model

[Kari Oikarinen]

On 28.1.2019 15.09, Jedrzej Nowacki wrote:
> On Thursday, January 24, 2019 3:18:59 PM CET Kari Oikarinen wrote:
>> On 24.1.2019 16.15, Edward Welbourne wrote:
>>
>>> Kari Oikarinen (24 January 2019 15:02)
>>>
>>>> The rest of the paragraph talks about a situation where we will have two
>>>> stable
>   branches alive at the same time. Typically we don't, because
>>>> once 5.x+1 is created, 5.x is closed.
>>>
>>>
>>> Not quite: once 5.x+1 is *released*, 5.x (if not LTS) is closed
>>> (unless we have a pressing reason to release another 5.x.y).
>>> So, in the interval between 5.x+1 branching and releasing,
>>> we have three branches.
>>
>>
>> Right, so typically we indeed have two stable branches open. Thanks for
>> correcting me.
>>
>>
>>>
>>>
>>>> But 5.12 is an LTS version, so it will still stay open.
>>>
>>>
>>> Indeed.
>>>
>>>
>>>> But at what point (under current process) would be switch it to
>>>> cherry-pick only
>   mode? I don't remember when it happened for 5.9. It
>>>> could be when 5.13 is created and then there would be no release blocked
>>>> by waiting for a merge.>
>>>
>>> We switch to cherry-picking into 5.12 when 5.14 is created.
>>> See QUIP-5,
>>> * https://quips-qt-io.herokuapp.com/quip-0005.html
>>>
>>> So creation of 5.14 switches our merge pattern from 5.12->5.13->dev
>>> to 5.13->5.14->dev and the 5.14 release (probably) closes 5.13.
>>> Again, we could of course change that.
>>
>>
>> Yes, but I was attempting to describe the current approach and messed it
>> up.
>   
>> -- 
>> Kari
> 
> 
> Well, you are still right about the fact that 5.x.z is not in cherry-pick mode
> always. How it can happen that people involved in the process aren't always
> correct about branching model.  That is simply too complex to follow.

Yeah, being hard to understand is a disadvantage of the current model.

Part of the difficulty is also just the need to be aware of the current status
of the branches with respect to release status. Your cherry-pick proposal dodges
that with the keywords used in Applies-to field. It requires the bot to
understand that. If you take that away, I would guess that contributors would
not find it easier to pick all the correct branches to cherry-pick to compared
to picking the right branch to submit to.

I could imagine a similar approach used for current model to help in choosing
the right branch to submit. So picking from dev, stable, LTS and LTS-strict
would tell you the correct branch to submit to.

Also about the releases waiting for merges. Even if we have two stable branches
active and we would then have a blocker relevant for both 5.13.0 and 5.12.2,
there is no need to wait for merges. If those release branches already exist,
then they won't be merged into. So waiting for the fix to be merged into 5.13
won't change the cherry-pick operation; the two heads and the common ancestor
stay the same. Thus once the fix lands in 5.12.2, it can then be directly
cherry-picked to 5.13.0. It would have to be cherry-picked anyway.

> Btw. it also may add one merge to all merges count I mentioned befor

True.

-- 
Kari