> On 24 Jan 2019, at 14:10, Edward Welbourne <[email protected]> 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.
Either way it can fail though: if the bot tries too hard to keep the patches in order, we’ll all waste time whenever a lot of patches “depend” on one that is failing to be cherry-picked to a release branch. (So then isn’t it similar to merging change sets from feature branches, in that the whole branch is an all-or-nothing deal? That’s what I dislike about how GitHub does it.) But if we don’t keep them in order, it will be the same as now when trying to stage any given patch: individual patches will need rebasing sometimes, and that’s also extra hassle. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
