On Wed, 23 Jan 2019 at 17:53, Jedrzej Nowacki <[email protected]> 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. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
