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