[Development] Proposal: New branch model

Edward Welbourne edward.welbourne at qt.io
Thu Jan 24 14:10:11 CET 2019

Dnia czwartek, 24 stycznia 2019 09:08:29 CET Liang Qi pisze:
>> My concern is about "cherry-pick" a series of changes for a big
>> feature, especially during the period to have "dev" branches for both
>> 5 and 6. I don't have solution for this issue yet.

Jedrzej Nowacki (24 January 2019 11:53)
> My assumption is that bot would cherry-pick them in the same order in
> which patches got integrated to dev. That way we could reduce amount
> of issues. Of course if the first patch from a series causes conflicts
> then all other would also be in conflict.

Well, the *initial* cherry-pick-and-send-to-Coin can be made to happen
in the same order; but after that, any that didn't get through on the
first pass are going to be apparently-unrelated changes waiting to go
into the destination branch.  The script might be able to look at the
upstream dev versions of its cherry-picks and reproduce the dependencies
among them, but that's going to get tricky when some of those upstream
changes got integrated out of order (because some of them were merely
later in the branch, without a strict dependence on those earlier) or
some of them succeed on the first pass while others, before and after
them on the original branch, fail.  Either you'll end up losing some
dependency relations or you risk having things on my branch depend on
other folks' unrelated changes that were just upstream of my branch,
that haven't yet made it through cherry-picking.  This isn't fatal, as
the developer taking care of the post-failure fix-up and/or retries can
stage despite a dependency missing, but it'll cause some pain at times.

There are also potential problems where I push to dev a fix for some
issue, followed by a change that undoes a kludge-around whose root cause
is the issue I've just fixed, but which was put there to fix some
seemingly unrelated issue.  Even if the first fix's cherry-pick hits a
conflict or fails to integrate, it's entirely possible that the removal
of the kludge-around gets through on the first pass; and that could be a
problem.  With luck there's a test for what it kludged round, that'll
prevent it integrating; but, if there isn't, that issue resurfaces in
the target branch until the real fix's cherry-pick lands.

Automated cherry-picking implies various complications that we haven't
fully explored; whereas merges have some well-established reliable
properties that avoid many of those complications.  Engineers prefer
what's known, from experience, to work over things that sound like they
might.  OTOH, as Ville points out, other projects do use cherry-picking;
so perhaps we need more information from such projects,


More information about the Development mailing list