Volker Hilsheimer wrote: >> Sounds nice, but the reality is that this has not been the >> case. Forward-merging hasn't worked without a fair bit of >> hand-holding; one big difference is that forward-merging is a >> centralized process, so the hand-holidng had to be done by the merge >> master who has nothing to do with either the code that’s being >> modified, or the patch that caused conflicts. And nobody wants to be >> the merge-master.
Filippo Cucchetto (6 December 2019 17:42) replied: > And who does backwad merges? the CI automatically? Indeed backward > merges don't suffer for conflicts We've been doing forward *merges*. The proposal is to change to doing *cherry-picks* backwards. At present, a merge-bot automerges on a regular basis and pushes the result to a Gerrit review. If there's a conflict, it stops there, adds as reviewers some developers named in commits it thinks are implicated (it's often wrong) and waits for developers to sort out the mess. If there were no conflicts, it auto-approves itself and sends the merge to Coin; if that fails, it likewise adds some developers to the review and leaves us to sort out the mess. In much the same way, the proposed new system would auto-cherry-pick each commit back to each branch its Pick-to: footer nominates. I guess we'll make the owner of the original review the owner of these new reviews and add whoever approved the original as reviewers of the new one. If there's a conflict, it'll stop there and leave them to sort it out. If not, it'll auto-approve and send to Coin. If that fails, the author and reviewers get to sort it out. Superficially very similar but: * The merge-'bot has to guess which commits caused the conflict - it's often wrong - and from that interpolate who to drag into its review; the pick-'bot will be dragging in folk who are definitely familiar with at least one of the commits implicated in the conflict. * Even when the merge-'bot does get the right folk to drag in, a fair bit of time may have elapsed since their work got integrated, before they're faced with sorting out the conflict; whereas the pick-'bot will be bringing problems to developers' attention *immediately* after their changes integrated, while their understanding of that work is still fresh in their minds. * The pick-'bot will do its job once and leave you to sort any mess out at your own speed. The merge-'bot has a schedule to keep up with, so if you haven't got the fixed merge integrated before it runs again, your work gets stomped on by a new merge-attempt and you have to re-do all your conflict resolutions and get folk to approve the result. >> Also (as people confirmed during the discussion at CS) the forward >> merging process causes significant delays. Fixing a bug in 5.15 that >> you would like to modify to use modern C++, or refactor whatever >> smelly code you might have run into, in dev means that you spend >> weeks on a simple bug fix; merging it into 5.15; waiting for forward >> merging (and potentially integrations) to succeed; adjusting the >> merged change in dev; merging into dev. > I don't get this one because even if you push your fix directly to dev > you still need to test your fix in previous branches. Furthermore if > your fix used a modern C++ syntax chances are that you cannot backport > to previous branches. Thus you still need to code the fix for 5.15 C++ > syntax, test it in dev, test it in 5.15, integrate in both and then > eventually make another commit on dev for porting your fix to new > modern c++ syntax. Do the best fix you can on dev, using as modern a dialect of C++ as it allows. If there are problems for older branches, Coin should reveal them when integrating and you can sort them out when they come up, on the branches to which they're relevant. You can, of course, re-use one resolution of the problems across all the branches for which it works, but at least you'll be doing all the inter-C++-version porting all in one go, the day after your original work integrated to dev. Compare to the present situation, where you make the best change you can on an old branch. That merges up as an anachronism into all later branches that support a more modern C++. At some point you discover it's done so (if you haven't forgotten about it while waiting for the merges to go through - which tends to happen, see what Volker noted above) and can modernise it, but it's now several weeks since you did the original work, so it's not as fresh in your mind as it would be if you were doing the reverse *the day after* your original work integrated. > Supposing to have a bot for auto forward merges We do indeed: https://codereview.qt-project.org/q/owner:qt_forward_merge_bot%2540qt-project.org > (as i understood you're supposing to have for backward merges) i don't > see any difference. I hope the explanations above shed some light on why those of us who've been involved in the existing process believe the proposed new process will make a significant difference. We'll still have a 'bot, but it'll make fewer guesses (hence fewer *wrong* guesses). We'll still sometimes have to sort out a mess after our earlier work didn't get to where it should be going, but we'll get to sort it out immediately, rather than after some haphazard (often long) delay. And the work shall be distributed, rather than lumped into the hands of a few. Eddy. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development