[Development] Proposal: New branch model

Sergio Ahumada sahumada at texla.cl
Thu Jan 24 19:46:35 CET 2019


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
sahumada at texla.cl





More information about the Development mailing list