[Development] Proposal: New branch model

[Ville Voutilainen]

On Wed, 23 Jan 2019 at 17:53, Jedrzej Nowacki <Jedrzej.Nowacki at qt.io> wrote:
>   Proposal in short: let's use cherry-pick mode everywhere.
>
>   All(**) changes would go to dev. From which they would be automatically
> cherry-picked by a bot to other branches. The decision to which branch cherry-
> pick, would be taken based on a tag in the commit message. We could add a
> footer that marks the change risk level as in quip-5 (http://quips-qt-io.herokuapp.com/quip-0005.html), so for example "dev", "stable", "LTS". By
> default everything would be cherry-picked to qt6 branch unless "no-future" tag
> would be given. Of course we can bike-shed about the tag names.
>
>   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
>   - simpler for new contributors, always push to dev
>   - in most cases a reviewer does no need to know what the current version
> number is
>   - conflict resolution is distributed and affects mostly the author of the
> change
>   - 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

+1 Strongly in Favor of this branching model. I use it in other
projects like GCC, I understand how it works, my
fixes land instantly on branches instead of waiting for a dedicated
person responsible for a merge to do it,
I never run into a situation where I fix a compilation problem in
5.12, someone else fixes it in 5.11, we all scratch
our heads about why we're duplicating work and also scratch our heads
how to resolve the merge conflict.
I can answer the questions about whether my fix will or will not land
in other branches and when, and I can make
sure it does land on the right branches because I can do those
cherry-picks myself, and I will, because I never
expect a magical merge to do it for me.

I consider this proposal a proposal to make our branching model
normal, regular, and unsurprising.