[Development] Proposal: New branch model

[Allan Sandfeld Jensen]

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.

'Allan