[Development] Proposal: New branch model
olivier at woboq.com
Thu Jan 24 08:03:17 CET 2019
On 23.01.19 16:51, Jedrzej Nowacki wrote:
> 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
> 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