On 24.1.2019 15.10, Edward Welbourne wrote: > Dnia czwartek, 24 stycznia 2019 09:08:29 CET Liang Qi pisze: >>> My concern is about "cherry-pick" a series of changes for a big >>> feature, especially during the period to have "dev" branches for both >>> 5 and 6. I don't have solution for this issue yet. > > Jedrzej Nowacki (24 January 2019 11:53) >> My assumption is that bot would cherry-pick them in the same order in >> which patches got integrated to dev. That way we could reduce amount >> of issues. Of course if the first patch from a series causes conflicts >> then all other would also be in conflict. > > Well, the *initial* cherry-pick-and-send-to-Coin can be made to happen > in the same order; but after that, any that didn't get through on the > first pass are going to be apparently-unrelated changes waiting to go > into the destination branch. The script might be able to look at the > upstream dev versions of its cherry-picks and reproduce the dependencies > among them, but that's going to get tricky when some of those upstream > changes got integrated out of order (because some of them were merely > later in the branch, without a strict dependence on those earlier) or > some of them succeed on the first pass while others, before and after > them on the original branch, fail. Either you'll end up losing some > dependency relations or you risk having things on my branch depend on > other folks' unrelated changes that were just upstream of my branch, > that haven't yet made it through cherry-picking. This isn't fatal, as > the developer taking care of the post-failure fix-up and/or retries can > stage despite a dependency missing, but it'll cause some pain at times. > > There are also potential problems where I push to dev a fix for some > issue, followed by a change that undoes a kludge-around whose root cause > is the issue I've just fixed, but which was put there to fix some > seemingly unrelated issue. Even if the first fix's cherry-pick hits a > conflict or fails to integrate, it's entirely possible that the removal > of the kludge-around gets through on the first pass; and that could be a > problem. With luck there's a test for what it kludged round, that'll > prevent it integrating; but, if there isn't, that issue resurfaces in > the target branch until the real fix's cherry-pick lands. > > Automated cherry-picking implies various complications that we haven't > fully explored; whereas merges have some well-established reliable > properties that avoid many of those complications. Engineers prefer > what's known, from experience, to work over things that sound like they > might. OTOH, as Ville points out, other projects do use cherry-picking; > so perhaps we need more information from such projects,
We're also using cherry-picking ourselves in LTS branches. At least older ones, 5.12 is not at that mode yet. As far as I know it has been working well. Since the problems with cherry-picking come up as the changes pile up and concurrent development happens, those are largely avoided in the older branches. A less ambitious change to our current process could be moving branches into cherry-picking mode earlier. That would limit the count of currently active branches that we need to merge between. Of course the effects of such a change would be much smaller also. But just to mention it because I don't think anyone has mentioned it yet. -- Kari _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development