On Thursday, January 24, 2019 7:46:35 PM CET Sergio Ahumada wrote: > On 24.01.19 14:10, Edward Welbourne wrote: > > 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, > > I have seen this implemented, similar to what Jedrek proposed, but the > decision where to cherry pick is in JIRA, not via git annotations/marks. > > This requires the Release Manager to keep an eye on which changes have > not being propagated to all branches, though. > > fully automated process, the fix is pushed to the oldest branch (5.12) > and then propagated to newer versions (5.13, dev, etc). Change is > automatically cherry-picked, updated the commit message, uploaded to > gerrit, automatic Code-Review+2, automatic stage, automatically merged > if CI passes. > > propagation rate failure is around 20% of, mostly due to: > - merge conflicts (will happen, for sure) > -- genuine merge conflicts > -- change was already cherry-picked manually > -- dependencies missing > - ci failures > -- mostly due to infrastructure issues > -- ci does not know how to handle dependencies > > advantages: > - when it works, everybody is happy > - pass rate is very high (around 80%) > - one can run git-cherry-pick -n and add additional info in the commit > message > - can be tuned up to exclude some changes from being propagated (the > bot, not git-cherry-pick itself) > > disadvantages: > - most developers don't know how to handle the propagation failures > -- I already moved on and am working on something else, do you want me > to switch to '5.19' to fix a change I did in '5.12' ? oh, and it failed > in '5.18' as well? why don't you do merges instead and leave alone? > [true story :-)] > - change can pass the CI and found to be problematic later on > -- oh, I need to fix my change in 5 branches now? [Gerrit 2.14 has a > cherry-pick button in the UI now, so this is not a problem with that > version] > - automated cherry-pick process/bot/script has to be maintained > -- one change not merged might lead to lots of changes to fail with > merge conflicts, staying open in gerrit forever > -- hey, can you add intelligence to the bot so it know how to merge the > open changes once the dependency is merged? > -- hey, can you add intelligence to the bot so it can cherry-pick them > in the right order?) > - yes, git-cherry-pick does weird things. I have seen it cherry-picking > the same change twice without problems (same line twice in the file, I > think I was an include guard that compiled but behaved weirdly, or similar) > > my 2€
Thank you for the story, do I get it correctly that the most of problems are social and global flakiness of the system? Cheers, Jędrek _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
