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€
--
Sergio Ahumada
sahum...@texla.cl
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
