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

[Marc Mutz]

On Thursday 08 September 2016 09:12:32 Marc Mutz wrote:
> 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.

I just came to realise another reason against cherry-picking:

Qt 5.6 is C++98-only while 5.7+ is C++11. That means patches that will be 
developed against 5.7+ will very likely have C++11 constructs in them that 
won't work in Qt 5.6.

That means that in order to backport, the code needs to be de-C++11-ified, 
which in turn means the usual reasoning for cherry-picking as a stability 
feature (it's been integrated already once successfully) falls flat on its 
face, because the code submitted against 5.7+ must needs be changed (forgive 
my Victorian) in the process of cherry-picking to 5.6, invalidating any test 
coverage it may have had as part of the younger branch.

To avoid the guaranteed merge conflicts from cherry-picked-and-changed, 
commits, you'd need to ban any non-cherry-pick changes to 5.6, which 
effectively means that no developer does any work on 5.6 anymore. Everyone 
will rely on the CI, and the CI only.


OTOH, with very few exceptions such a Q_FOREACH, code that successfully 
integrated into 5.6 will successfully integrate in 5.7+.


In light of this I continue to vote for keeping the "no-cherry-picks allowed" 
policy that has served us well over the Qt 5 years.


If merging is a bottleneck, I think we as contributors just need to unlearn 
that 5.6 changes magically show up in dev a few days later. Before Liang 
became the designated merge-monkey (that's not derogative, that's the 
technical term! :), we had to wait up to a month for a change to percolate up, 
and that was with fewer active branches in-flight. We survived, and Qt wasn't 
1/6th merges (uneducated guesstimate based on equating Liang with merges and 
applying that to http://www.macieira.org/~thiago/qt-stats/current/qt-
all.author.absolute.png (2016W38)).

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