[Development] Proposal: New branch model

Jedrzej Nowacki Jedrzej.Nowacki at qt.io
Thu Jan 24 14:15:55 CET 2019

Dnia środa, 23 stycznia 2019 22:09:30 CET Allan Sandfeld Jensen pisze:
> On Mittwoch, 23. Januar 2019 21:42:35 CET Edward Welbourne wrote:
> > Jedrzej Nowacki wrote:
> > >>  Advantages:
> > >>  - no waiting for merges, a fix can be used right away after
> > >>  
> > >>    integration
> > >>  
> > >>  - faster propagation of fixes targeting all branches, as there are
> > >>  
> > >>    no merges of merges
> > 
> > Alex Blasche (23 January 2019 18:09)
> > 
> > > This is pure speculation because you potentially triple (or worse) the
> > > amount of individual patches requiring a merge in gerrit when you
> > > consider that you want to at least merge to 5.9, 512, dev and qt6. I
> > > don't see this prediction come true.
> > 
> > Well, as soon as it hits dev, the patch is cherry-picked to every branch
> > that its footer says it belongs in.  Those branches where all goes well
> > see it one integration later.  Each branch that has a conflict needs
> > that resolved before we get to that second integrtion.  Contrast this
> > with a 5.12 -> 5.13 -> dev chain of merges, where dev doesn't get the
> > change that landed in 5.12 (even if that change could land in dev
> > without conflict) until
> > 
> >  * there's been some delay between their change being accepted in 5.12
> >  
> >    and the next merge-bot run
> >  
> >  * everyone who made change to 5.12 that conflicted on merging to 5.13
> >  
> >    has advised Liang on how to resolve their conflicts
> >  
> >  * we've got the result through integration into 5.13
> >  * everyone who's made changes to 5.13 or (as possibly just amended in
> >  
> >    merging) 5.12 that conflicts with anything in dev has again advised
> >    how to resolve their conflicts
> >  
> >  * and we've got the result through a second integration, into dev.
> > 
> > When nothing but the change being considered has a conflict along
> > the way, that's twice as long; and any change to an upstream branch,
> > that does have a conflict, introduces delay for all the other changes
> > that landed in that branch, even if they don't have conflicts.  In the
> > middle of summer, when lots of folk are away on holiday, getting help
> > with resolving conflicts isn't easy - the folk who know those commits
> > won't be back for a month - and all changes, no matter how urgent, get
> > stuck behind any conflict we can't work out how to resolve.
> > 
> > So no, Jedrzej's claim is not *pure* speculation; it's at least quite a
> > lot adulterated with reasons to believe that many changes would, under
> > his scheme, propagate to all branches they're destined for sooner than
> > happens with our present scheme.
> No, it is speculation, and it optimizing the least important case: bug-fixes
> in dev. Dev is the branch that can wait the longest to get a bug-fix, the
> stable branch is the branch that need it the most urgent. And fixing a bug
> in 5.12 now means you first fix it where you need it (5.12), then rewrite
> it for dev, then resolve the inevitable conflict back so it can be merged,
> all waiting for bots and release teams to stumple into the issues and
> delaying the next 5.12.x release.

First, I do not agree that dev is less important. Dev is the base for all 
future releases. Even if a current release is broken in some way, the next one 
should not be. We can not focus on short term only.

Typical use case I have with bug fixing in dev is when I develop a feature and 
I see let's say a memory leak in the code that I'm modifying or somewhere 
around. With the merge model I have four options now:
1. Pretend that I haven't seen it
2. Make a fix in LTS and develop my feature separately, counting on the merge 
master to resolve conflicts
3. Do the fix only in dev
4. Make a fix in LTS and wait for all merges before I continue with the feature
If it is a memory leak then it is not as bad as memory corruption and crashes, 
as at that point I can not use approach 2. Option 1 and 3 are not great from 
QA perspective. Option 4 is slow and kills motivation for development.

Last, but not least. The release branches are already in cherry-pick mode, so 
again it is not different, amount of conflicts is the same, true one needs to 
solve them earlier,  but on the other hand you can prepare the conflict 
resolution in parallel, while waiting for the integration. In your example you 
picked an easy target, but try the same with 5.13 and case of a fix targeting 
LTS. With the current model you need one merge (5.12 -> 5.13) and then one 
cherry-pick (5.13 -> 5.13.x). Of course you could cherry-pick from LTS 
directly to the release branch, but then you are acknowledge that merges are 
hurting us in terms of release speed. 


More information about the Development mailing list