[Development] Notes on "Managing Qt's branches" session @ QCS 2016
Marc Mutz
marc.mutz at kdab.com
Sat Oct 1 10:24:59 CEST 2016
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
More information about the Development
mailing list