[Development] Qt branches & proposal how to continue with those

[Edward Welbourne]

Tuukka Turunen (1 February 2018 16:22)
> I think keeping 5.9 open a bit longer has benefit due to it being an
> LTS.

The benefit looks small, to me.

If I have to cherry-pick back to LTS, it's for an important issue; I've
just done that for QTBUG-66076 because it got reported against 5.9.4,
after I'd fixed it on dev (it made it into 5.10.0).  Maybe it's because
I can see bugs in code without needing a bug report to lead me to them,
but I'm used to this happening - I don't always know, when I'm fixing an
issue, whether it's important enough to warrant starting out in 5.9; and
I'm conservative enough to not put fixes into LTS unless I positively
see a definite need for them (e.g. an actual bug report).  Furthermore,
a fix cherry-picked back to LTS has the virtue of having seen relatively
thorough testing in other branches, reducing the risk of "surprises".

Having 5.9 at the start of the merge-chain incurs some hassle for anyone
who does end up needing to cherry-pick back to it, and may incur
conflicts during merge-up when that's happened; which encourages folk to
put changes into 5.9, just to be on the "safe" side (i.e. avoid that
hassle), when the fix might not actually be critical enough to belong
there - which isn't so good for the "safety" of LTS; every fix incurs a
risk of breakage; if that fix wasn't really needed in LTS, then this is
needless risk.  Furthermore, fixes introduced in 5.9, for merging up to
other branches, haven't been as rigorously tested as fixes that have
been round the grind in a later branch - which can discover unexpected
side-effects, that a fix developed on 5.9 will have introduced in LTS.

So you get a little convenience out of keeping 5.9 in the merge chain,
which I can see the virtue of up until about the point where 5.10.0 got
released, but that convenience comes at the price of added hassle for
those whose fixes on other branches turn out to be needed in LTS, plus a
bunch of added risk to the stability of LTS.

> It adds a bit merge effort, but should be manageable if 5.10 is out of
> the picture. We should aim to increase stability, as is the target of
> strict mode. Perhaps we could simple agree to now on push only items
> that match strict mode criteria to 5.9, rest goes to 5.11 or dev? Move
> to cherry pick mode for 5.9 a few months later then.

I get twitchy about the merge pattern being 5.9 -> 5.11 -> dev, without
passing through 5.10 on the way.  It'll lead to folk expecting things to
be in 5.10 when they aren't.  Once 5.10 is no longer part of the merge
chain, 5.9 should be in cherry-pick mode.  That change will make folk
more aware that their changes to 5.9 aren't getting into a putative
5.10.2, if it ever is needed, so there's a better chance they'll
evaluate whether it's needed there and, if it is, cherry-pick it to 5.10
ready for that (or fix it on 5.10 in the first place, if it stays in the
merge chain).

If we're going to stop merging up from 5.10, after 5.10.1 branches, then
we should switch 5.9 to cherry-picking mode at the same time; and allow
cherry-picks back to 5.10 for critical issues, targeting a 5.10.2 that
we hope we won't need but should be ready to produce if we do.

However, see Kevin's point: we *know* we'll have security fixes for
qtwebengine; our plan *should* take account of that.  Shall 5.11 and
5.11.1 be close enough to 5.10 that those on 5.10 can sensibly be
expected to upgrade to them - in which case, why aren't they called
5.10.2 and so on ? - or do we need to plan a 5.10.2 simply for
qtwebengine's sake ?  Or is it time we genuinely separated qtwebengine's
release schedule from the rest of Qt ?  Would that even work ?

We've upped the tempo of releases: this is, of course, good - but it
comes with costs.  When I'm fixing a bug, I fix it on dev and wait for
it to be reviewed before worrying about which branch it belongs on -
because, all too often, the branch I *would* have put it on at the start
has been released before anyone reviews what I've changed.  So I leave
that decision until I know which branch is appropriate *when the fix
gets past review* - but that tends to bias me towards putting it on a
later branch than it might have belonged on.

Pause to consider another model: we close 5.10 transiently, during the
life-time of 5.10.1, so that 5.10.1 takes 5.10's place in the merge
chain; we re-open 5.10 after 5.10.1 releases, only for critical fixes
that would be needed for a 5.10.2 release, if we can't avoid one.  When
5.10.1 closes, we'd do a merge from it to 5.10, which would then
re-open; then we merge up from there.  We would seldom need to merge up
from 5.10, reducing its contribution to the merge chain; and taking it
out of the chain during 5.10.1's stabilisation period makes sense.

As long as we put 5.9 into cherry-pick mode during that, we'll have a
merge chain that looks like:
  5.10.1 -> 5.11.0 -> 5.11 -> dev
and changes to
  5.10 -> 5.11.0 -> 5.11 -> dev
before reducing to
  5.10 -> 5.11 -> dev
with the 5.10 -> steps always being low-bandwidth.  The problem right
now is that we're adding stabilisation branches to
  5.9 -> 5.10 -> 5.11 -> dev
A three-step flow is only really tolerable transiently (e.g. during the
lifetimes of stabilisation branches); we need to cut 5.9 loose to keep
the merge chain manageable.  If we also lock x.y during the
stabilisation of x.y.z for any z > 0, to take x.y out of the merge
chain, we can keep the chain short aside from transiently during
releases.

We then have a normal two-step chain (5.10 -> 5.11 -> dev) , to which we
sometimes add a third step for a first release (5.10 -> 5.11.0 -> 5.11
-> dev) and in which we sometimes replace a released major-version
branch with a stabilisation branch off it for its next release (x.y.z
for z > 0 replacing x.y in the chain).  It's only every three-step
during a first release stabilisation phase; it's never more; and the
first step is usually low-bandwidth.

Both 5.10.1 and 5.11.0 are transient, so should only force a few merges;
each needs merge after it release, each may need merges due to critical
things that break development on later branches, so need to be merged up
promptly - although we *should* have few of those, precisely because
these are meant to be stabilisation branches.  Killing 5.10 just because
these transients make the chain too long looks like the wrong answer, to
me,

	Eddy.