[Development] Proposal: New branch model

[Shawn Rutledge]

> On 24 Jan 2019, at 14:10, Edward Welbourne <edward.welbourne at qt.io> 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.

Either way it can fail though: if the bot tries too hard to keep the patches in order, we’ll all waste time whenever a lot of patches “depend” on one that is failing to be cherry-picked to a release branch.  (So then isn’t it similar to merging change sets from feature branches, in that the whole branch is an all-or-nothing deal?  That’s what I dislike about how GitHub does it.)  But if we don’t keep them in order, it will be the same as now when trying to stage any given patch: individual patches will need rebasing sometimes, and that’s also extra hassle.