[Development] Proposal: New branch model

Olivier Goffart olivier at woboq.com
Thu Jan 24 08:03:17 CET 2019

On 23.01.19 16:51, Jedrzej Nowacki wrote:
> Hi,
>    It is time to rethink our branch model. [...]

You do not explain why the proposed solution solve the "problem". I actually 
think it is quite the contrary effect of what you think: the proposed model 
will slow down patch propagation, and increase the amount of work.

Let's start by looking at the "problem"
>    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!
So we have only ever have one release branch. Therefore the current model works 
great (your own words).

> 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.

> 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.

>    It is slow:
>    The merges take time. We produce a lot of code, we have a lot of tests that
> needs to pass. Even single failure delays merge propagation by at least one
> day. If by bad luck, the merge contains some API incompatible changes an
> intermediate jump through Qt5 integration is required, that adds at least 3
> days of delay.

Incompatile changes should not happen in a release branch normally. (Or very 
seldomly, as fixes on new API)
And as it has been said already, there is no priority to get changes quick in 
the dev branch. On the other hand, haing the change faster in the stable branch 
are more important, for it is going to be released first. So your model would 
delay the change in the branch where it matters more.

[...]>    - Stay with the current solution <= the merge effort is too big and 
qt6 is
> expected to cause conflicts that really should not be solved by one person

Again, I don't see how the proposed model reduce the amount of conflicts.
If the "one person" is the problem, then nothing prevents you to assign more 
people to the job. One easy way is already to share the different modules 
(repositories). But with some cooperation it is also possible to share the work 
accross directories, or by number of commits. One can also be pragmatic and 
revert most problematic commit (that fails tests) in dev or stable, then let 
the author work at it again.


Woboq - Qt services and support - https://woboq.com - https://code.woboq.org

More information about the Development mailing list