[Development] Proposal: New branch model

[Volker Hilsheimer]

On 23 Jan 2019, at 22:09, Allan Sandfeld Jensen <kde at carewolf.com<mailto:kde at carewolf.com>> wrote:

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


More people working and building against dev helps keep dev more stable (by virtue of discovering breakage sooner), and the proposal encourages more people to work on dev. That can be a good thing.

Urgency to get fixes into a stable branch is an argument that has come up a few times. The current 5.12.1 release seems to be delayed because some changes made it into 5.12 that shouldn’t have been there in the first place (given the definition of “stable”). It would be interesting to see some data about how many point releases we had to delay because “highly desirable fix for old bug was stuck in the process” vs “regression was introduced in a stable branch and only discovered during release testing”.

Without data, I would speculate that perhaps a model that leads to fewer changes made to stable branches because it requires an explicit decision (and perhaps extra work) to get changes there is not such a terrible idea. And making the work to make changes to a stable branch, ie the cost of maintenance, very visible is also a good thing.

Either way, nothing in the proposal prevents us from developing and push a fix for 5.12, and then develop a different fix for dev that we don’t cherry pick into 5.12 or other stable branches. This should be an exception, used in urgent situations where indeed we can’t wait. For those cases, there’s no merge conflict in the first place in the new model (because there’s no merge).


Volker



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190124/95d4650f/attachment.html>