[Development] Proposal: New branch model

[Alex Blasche]

>________________________________________
>From: Development <development-bounces at qt-project.org> on behalf of Jedrzej Nowacki <Jedrzej.Nowacki at qt.io>
>  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

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.

BTW how does this work for change files? I hope we don't have to look in release tags to find the change log for a particular release.

>  - simpler for new contributors, always push to dev

Really? Me being the new guy wanting to fix a bug in 5.12 need to magically know that I have to push to dev and know about a magic cherry-pick logic and a magic tag in the commit log. Right now I need to know I want to fix in 512 and push to it. Also the current model does not bother the new guy with myriads of potentially following cherry-picks which may require a larger commitment than he is willing to give. The entire bot logic section below is another non-implicit logic.

>  - in most cases a reviewer does no need to know what the current version
>number is

But he does, because you require the right commit tag in the log, don't you?

>  - conflict resolution is distributed and affects mostly the author of the
>change

The merge problems we have today don't disappear. The merge problem is shifted from full time developers to once in a life time contributors. The once in a lifetime contributor might not care anymore. To me this sounds like a way to shift the hard problem to somebody who has the least knowledge, commitment and time. The loser will be the Qt stable/lts branches. Add the explosion of changes towards the CI.

True, the distribution is a plus. can we possibly apply this thought to the current approach? How about we distribute the current merge coordination among more experienced developers. If you combine this with simpler dependency management were we don't have to wait for qt5.git to merge, the merge task distribution becomes easier.


>  - documents a change intent, which may be useful for people keeping own
>forks
>  - over time with increased amount of conflicts old branches, in natural way,
>stay untouched

>  Disadvantages:
>  - git history would be a bit wilder, "git branch --contains" would not work
>  - commit messages in some branches would have kind of ugly footer as an
>effect of "cherry-pick -x"
>  - there is a chance, that some cherry-picked commits may be left forgotten
>in gerrit after a failed integration

I see this as a serious problem and it was one of the biggest if not *the* advantage of the current system. And the most experienced devs were responsible for ensuring it.


--
Alex