[Development] Proposal: New branch model

[Kari Oikarinen]

On 24.1.2019 15.10, Edward Welbourne wrote:
> 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,

We're also using cherry-picking ourselves in LTS branches. At least older ones,
5.12 is not at that mode yet. As far as I know it has been working well.

Since the problems with cherry-picking come up as the changes pile up and
concurrent development happens, those are largely avoided in the older branches.

A less ambitious change to our current process could be moving branches into
cherry-picking mode earlier. That would limit the count of currently active
branches that we need to merge between. Of course the effects of such a change
would be much smaller also. But just to mention it because I don't think anyone
has mentioned it yet.

-- 
Kari