[Development] Notes on "Managing Qt's branches" session @ QCS 2016

[Marc Mutz]

On Wednesday 07 September 2016 08:37:01 Friedemann Kleint wrote:
> ** After 5.7 is closed and sanity bot is upgraded (to handle 
> cherry-picking), go into cherrypicking mode for 5.6. Developer is 
> responsible for doing the cherrypicking
> ** Cherry-picking technicalities need to be figured out: Let sanity bot 
> verify source ("cherrypicked from") the SHA1

I'm sorry, but this is nonsense. The source control system works by committing 
on the older branches and merging up. Cherry-picking from younger branches 
works against the source control system. We put up with cherry-picking for 
4.8, because there we dealt with separate repositories, but that doesn't make 
is a good model.

There's another aspect to this: I develop part of my patches on gt5.git/5.6 
and the rest on qtbase.git/dev. I guess for most people with non-unlimited 
processing power it will be similar. For sure this is the only way if your 
development focus is on qtbase (and you can't just submit your changes to COIN 
manually).

If I submit from the qt5.git/5.6 built, the changes have gone through testing 
in the stable branch. If I submit from there to younger branches, test 
coverage is not as good, but the point is that the stable branch receives the 
changes tested locally in-situ. If I change this to qt5.git/5.8 and cherry-
pick changes back to 5.6, all local testing will have been done in-situ for 
5.8, and when submitting to 5.6, no in-situ testing has happened locally.

IOW: cherry-picking causes *more* risk to the stable branch than submitting 
there and merging up. I am not convinced that the perceived security of having 
a patch integrated into a younger branch and then submitting it to the older 
branch outweights the loss of test coverage.

If the merging strain is too much, only merge 5.6 up once a fortnight/month.

Currently, it feels like there's

   5.6 -> 5.7
   5.7 -> 5.8
   5.8 -> dev
   5.6 -> 5.7

with maximum speed. That's nice for developers who are splitting changes into 
a bugfix part for 5.6 and a feature part for 5.8/dev, but it hasn't been like 
that in the past and we survived, too. And the git history looked cleaner, too 
:)

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts