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.
>> 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.
>> 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.
>> 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)
No, but they do happen in dev, which complicates merging things up to
dev - which, I suppose, was Jedrzej's point.
> 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.
The delay would only happen to things that got conflicts or on which CI
failed; and, as long as someone's eager to get the change into the
target branch, it's likely to be delayed by at most about a day. In
contrast, when we do have three branches, the fix in a release branch
takes several days to reach the stable branch and about a week to reach
dev.
When the fix is for breakage that's causing Coin failures, that's
holding up everyone for a week. We get this not so infrequently. With
the cherry-pick model, the fix would be done first in dev and would
reach all other affected branches probably within a day.
>[...]
>> - 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.
It doesn't. It does, however, ensure that conflicts are dealt with by
the people who made the change on one side of the conflict, while the
change is still fresh in their minds. That is probably better than
having the conflict resolved by someone who knows neither half of the
change. OTOH, it runs the risk that the other side of the conflict
won't be properly understood by those resolving it, creating an
asymmetry that's absent when the resolver is equally ignorant of both
sides.
> 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.
These are all good suggestions for how to improve the existing merge
process. I can believe they might be better than a change of process.
It would also motivate sharing our expertise in how to resolve
conflicts, which Is Good.
Eddy.
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
