[Development] Proposal: New branch model

[Edward Welbourne]

On Wednesday, 23 January 2019 11:01:53 PST Volker Hilsheimer wrote:
>>>> I think that’s fine. What’s much worse is having a fix in 5.12 and
>>>> not knowing how to deal with the merge conflicts into dev. That
>>>> means dev might regress, unless whoever authored the change is
>>>> willing to spend time on making it work. In the end, if
>>>> contributors can’t own their changes for all various branches of
>>>> Qt, then I much prefer for them to own the changes at least for
>>>> dev. And with Qt 6, this will become a much bigger problem.

Thiago Macieira (23 January 2019 20:10)
>>> The problem is I can turn this around and say that we introduce
>>> regressions into the older branches due to an improper cherry-pick
>>> that didn't conflict.

Dnia środa, 23 stycznia 2019 21:47:16 CET Edward Welbourne pisze:
>> and *that* is a concern that does bother me.
>> Of course, it's got to pass integration, as well as not conflict, but
>> that doesn't guarantee it hasn't broken something.

Jedrzej Nowacki (24 January 2019 15:11)
> Of course, but it is not a regression to the current system, we have
> the problem currently, right?

Only for LTS branches, to which relatively few changes get picked.

> We can introduce a regression in a release branch

Just to be clear: while some cherry-picks do happen to release branches,
that is not their normal model.  Changes for an imminent release should
be sent to its release branch in the first instance.  The only thing
that's different there is that *staging* gets to be reserved to the
release team.

The only branches to which we currently cherry-pick by default are the
LTS ones.  Here the problem Thiago points out is *a bit* mitigated by
attentive review and the fact that it's a past branch we know well and
reviewers likely have some clue about what changes have happened since
that might not mix well with the change being cherry-picked; but this
only mitigates the problem a bit (we forget details) and I have my
doubts about how well that would work if we had more past branches to
remember that much about (I routinely get confused about which branch
first got a given change, even of mine, much less by anyone else), so
I'm not sure the mitigation would scale to twice as many destination
branches for cherry-picking.

> by merging and cherry-picking without conflicts. On the other hand
> logic that doesn't apply cleanly has a higher chances of introducing
> bugs and therefore higher chance of causing release problems.

well, breakage on the next LTS branch, that'll show up in its next
release, since (non-LTS) release branches don't get cherry-picks (much).

> These changes are more visible in gerrit as opposite to somehow opaque
> merges. So in my opinion it is an improvement.

That doesn't help the folk doing the LTS release, if the cherry-pick
went in without conflict and without any integration test failing.
The first they know about it is RTA or, worse, later.
So the change is more visible, yes, but how does that help anyone ?

	Eddy.