[Development] Proposal: New branch model

[Kari Oikarinen]

On 24.1.2019 11.49, Edward Welbourne wrote:
> Olivier Goffart (24 January 2019 08:03)
>> Let's start by looking at the "problem"
> 
> Always a good place to start.
> 
> On 23.01.19 16:51, Jedrzej Nowacki wrote:
>>>     My impression is that the current model works great for a single
>>> release branch, but we have: 5.6 5.9 5.12 and soon we will have 5.13,
>>> that is without counting temporary patch level branches.
> 
>> But the LTS and patch level branches are already in cherry-pick mode!
> 
> Indeed: Jedrzej does here over-state the problem.
> 
>> So we have only ever have one release branch. Therefore the current
>> model works great (your own words).
> 
> We routinely have two branches other than dev that are merged up to dev,
> one via the other.  Thus, until 5.11 closed, we were merging 5.11 up
> through 5.12 to dev; once 5.13 branches, we'll be merging 5.12 through
> 5.13 up to dev.  Once 5.13 closes, we'll put 5.12 in cherry-pick mode
> and be back to just one (as we are right now, temporarily); but wne 5.15
> branches we'll be back to 5.14 -> 5.15 -> dev again.  Then, of course,
> we also have the 5.x.y branches transiently, which does complicate life,
> but I'm going to leave it out of my analysis.
> 
> So some of the time we have three branches, some of the time two,
> between which we merge; plus we have an LTS or two to which we
> cherry-pick.  (Which means we mix models.)
> 
> However, merge-mode always implies more delay for a change's propagation
> compared to the cherry-pick model, at least when the developer whose
> change is considered is eager to get it propagated.

In general it leads to a longer delay until the change is in all relevant
branches. It does however lead to a change getting into the branch closest to
release faster, because it doesn't need to get into dev first. Branches close to
release are an important case.

Yes, you can deviate from the process in urgent cases. But even if the release
is not right at the door to justify the deviation, the change landing sooner
gives more time to find any possible issues in it.

> 
>>> Merging through them is hard, we already had to use "cherry-pick
>>> mode" in some places. When we add to the picture dev and qt6
>>> branches, merging will be very, very hard. It is practically a full
>>> time job to update qt5 repository and coordinate all the merges now
>>> (thank you Liang!),
> 
>> But as other have already said, the total amount of work would still be the
>> same. Actually worse since one would have to manually stage the patch and fail
>> the tests and resolve the conflicts that happen between them as they may occurs
>> in different order.  Overall, i'd say this is much more burden for branches
>> which still are supposed to get lots of patches.
> 
> There would, indeed, be extra staging with the proposed model; and
> patches may land in a different order.  The latter bothers me more.

Add to that the fact that a long-lived branch that is cherry-picked to may lead
to having to resolve the same conflict multiple times. (As discussed elsewhere
in the thread.)

Especially so for qt6 branch, which would be getting almost every change made in
dev + API breaking changes preparing for Qt 6. How many changes will actually
have the no-future tag?

>>> shortly after qt6 branch opening amount of work will be much bigger.
> 
>> But I fail to see how the proposed model helps with that in any way.
> 
> ... and we'll eventually have to merge the qt6 branch with dev, which is
> going to be "fun" if they've had cherry-picks between them that have had
> conflicts (as we can expect) that have been resolved.  Whoever does that
> merge is going to wish we'd been using merges from dev to qt6 earlier.

If I understood the proposal right, there wouldn't be a merge from dev into the
qt6 branch. Rather the dev branch would be deleted and the qt6 branch renamed to
dev. It already has all the changes, except those with the tag no-future

-- 
Kari