> On 23 Jan 2019, at 18:09, Alex Blasche <[email protected]> wrote: > > >> ________________________________________ >> From: Development <[email protected]> on behalf of Jedrzej >> Nowacki <[email protected]> >> 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.
Yes, there will be a change in those branches in which you want your change to land. That’s not different from today. Each of these changes will be tested as part of a small set of changes, rather than as part of a bulk-merge that includes potentially a ton of changes. This is an improvement, as it makes smaller, more frequent changes, with a lower overall risk of failure. > 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. That’s a good point. What I have experienced in other projects is that the changes files are managed in the relevant branch, and then bulk-updated in the master branch once the ship has sailed. >> - 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. The new or casual contributors that want to make small changes can work on dev. If they can’t invest the time or energy to make their fixes or changes work in more stable branches, then that’s cool; the fix will just not be in any of those, unless someone else picks up the slack. 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. As for the learning curve and cognitive load introduced by the cherry-pick automation: The current branching model is not easy to learn or understand, and it is not just “fire and forget”, esp if my change causes merge conflicts that someone else that knows nothing about my change and perhaps the code I worked on has to deal with. Learning how I need to tag my change if I want it to be applied to more stable versions of Qt, supported by an augmented commit template, is probably easy. >> - 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? Reviewers review changes against dev. Of course the reviewers should confirm that this change is indeed suitable for cherry-picking into more stable branches, as requested by the tagging. If cherry-picking works without conflicts and without regressions, then the cherry-picked change doesn’t need another review. Just as today the merges are not code-reviewed. >> - 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. See above; if you can’t own your change in multiple branches, then make it in dev and accept that the bug won’t be fixed in an LTS series unless someone else does the work. Right now, off-loading the merge-conflict resolution to “someone else’s problem” is not effective, even if that someone else gets paid for it. The explosion of changes towards the CI is a problem of scaling the CI; that problem needs to be solved anyway, but is IMHO a poor excuse for favouring infrequent, large merges with lots of changes over frequently applying a small set of changes. > 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. With the suggested system, dev is the truth. All changes are made in dev, are tested in dev, and will be in all future releases made from dev. So we are not losing anything on the way. Perhaps something that we wanted to include in 5.12.x might not make it because the cherry-picking got stuck in the process. Ok, then it will be in 5.13. For P0 and P1 tasks, I think that’s extremely unlikely to happen; for everything else, we can live with that risk, I think (esp since whoever waited for the change will surely notify us, if we don’t notice ourselves). The current system has the chance that conflict resolution during merge into dev introduces errors, which could go unnoticed for a long time. Isn’t that scenario much worse? Volker _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
