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

[Edward Welbourne]

Marc Mutz said:
> 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.

Conversely, code developed in 5.6 shall avoid C++11 constructs; when we
merge to 5.7, we need to review to find C++11 usage we can apply, which
tends to get missed after merges.

> 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.

Back-porting doesn't *entirely* invalidate the stability evidence gained
in a later branch, any more than conflict resolutions in forward-merging
invalidate stability evidence gained in an older branch.  Of course, you
need to test after back-porting, just as you do after forward-merging,
but the existing test coverage is still valuable.

> To avoid the guaranteed merge conflicts from
> cherry-picked-and-changed, commits,

Not sure what you're referring to here.  Just to be clear, once we
switch to cherry-picking back to 5.6, we shall stop merging forward from
5.6, so there shall be no merge conflicts from those changes being
merged up into 5.7 again.  That would be dumb.

> 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.

That did seem to be the intent of those who proposed this, yes.  Of
course, there shall be *some* work on 5.6, but it shall be limited to
back-porting already-tested fixes and investigating bugs that are only
evident in 5.6.  That would be the point of LTS, IIUC.

> Everyone will rely on the CI, and the CI only.

Again, not sure what you mean here; and those doing back-ports shall of
course be doing local testing before they push, so not relying only on
the CI - where, in contrast, after a merge we *are* relying on the CI
and only the CI, except for the (relatively few) conflicts in each
merge, which do get review.

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

... but will, as noted above, contain pre-C++11 code in need of
C++1-ifying, after we've done sweeps through the code-base catching such
code and modernising most of what's in 5.7 and beyond; so we would need
to pay attention to each change flowing up from 5.6, to see what needs
such attention.  The advantage of cherry-picking is precisely that each
one shall need to be done attentively and reviewed, while merging only
gets review of its conflicts and happens quietly in the background, with
few paying attention to it.

> 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.

I remain unconvinced, see above,

	Eddy.