[Development] QtCS2019 Notes from "Branch Policy" discussion

[Edward Welbourne]

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.