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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development