[Development] Proposal: New branch model

Jedrzej Nowacki Jedrzej.Nowacki at qt.io
Mon Jan 28 14:37:18 CET 2019


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





More information about the Development mailing list