[Development] Which changes are suitable for 5.6?

[Edward Welbourne]

On Wednesday 07 September 2016 10:26:44 Olivier Goffart wrote:
>> The reason we should limit the changes to critical change is so than
>> "jumping through hoops" gets easier. Every patch we put there instead
>> of in a upper branch makes more work of merging, handling regressions
>> causing by this patch, having to work with an outdated code base.
>>
>> (In fact, I think maybe we should stop merging 5.6. Backporting
>> (chery-pick) proven patches might be more effective.)

Marc Mutz  replied:
> IMO, that's nonsense. I still remember this from 4.8. No thanks.

I can't remember 4.8 - I wasn't here that long ago.
Please share
* what was the process ?
* why was it painful ?  (... as your phrasing indicates it was)

> Why work against the (very good!) revision control system?

One of the nice things about git is that it supports many work-flows.
Using its support for cherry-picking does not "work against" it; indeed,
it's what we primarily do in Gerrit (and rebasing is just mass-produced
cherry-picking).  It also supports merging wonderfully well, of course.
So the real question is: what work-flow works best for us ?

> Anyway, seeing as neither you nor me are doing merges, I guess we
> should let that particular topic in peace for Liang and Eddy to
> comment on, if they so wish.

The branch-management discussion at QtCon decided in fact to go with a
switch to cherry-picking back to LTS once 5.7 closes.  Until then, we'll
be merging 5.6 -> 5.7 -> 5.8 -> dev, which is a painfully long chain,
but we endure it.  Once 5.7 drops out of the chain and 5.9 sneaks in,
however, we'll be merging stable -> release -> dev and cherry-picking
backwards from stable (initially 5.8) to LTS (5.6).  One of the
contributory factors to that choice is just the length of the present
merge chain (which slows propagation of changes); another is the
expectation that conflicts shall become more common when passing over
the dead 5.7 branch (and, eventually, more).  I was part of that
discussion and I am satisfied that this is a sensible way to move
forward - provided I can work out how to hack into sanity-bot the
necessary checks that cherry-picks reference the right sha1s.

If I read the past accurately, it was Marc who had supplied:
>>> Because the LTS is for users who _cannot_ update to newer Qts (for
>>> whatever reason, dropped platforms just being one of them). Pointing
>>> them to a newer Qt where their bug is fixed is not going to help them
>>> one bit.

On the other hand, pointing them to the fix in a newer Qt does, at least
in some cases, offer them the option of patching the version of Qt they
use.  It isn't adequate for all, but it is significantly easier for them
to cherry-pick one (typically self-contained, single-commit) bug-fix
rather than a whole new feature (typically split across several commits,
that may - thanks to the vagaries of Gerrit - have been split up across
a broad span of the git history).

Olivier replied:
>> You could say the same about any new feature.

and Marc followed up with:
> Of course not. A user needs to write code to use a new feature. A bugfix
> affects existing code.

That's actually an interesting way to draw the distinction.  Elsewhere I
see a doc vs code (only one changes in a bug-fix, both in a feature) way
to draw it; this gives a different classification.  There is a general
problem that - in between the changes that are clearly new features and
those that are clearly bug-fixes - there is a broad grey area where it
doesn't really help much to argue about whether the change is a feature
or a fix; it's a change, to be assessed as itself.  Whether it belongs
in a particular branch should be about its suitability for the releases
intended off that branch.

Sometimes we change default behaviour of a system; the client code
doesn't change, but its behaviour does; both the code and the doc
change, so the doc vs code classifier calls this a feature, while the
new code classifier says its a bug-fix.  This is indeed quite apt: some
such changes fix an inappropriate default behaviour, others enable new
ways of using the system.  Whether they're bugs or features isn't really
the important question: whether such a change should go into LTS depends
on whether LTS use-cases are likely to be broken by the change and
whether LTS use-cases are likely to be saved from grief by them.  If we
update the list of cipher-suites used by default in SSL (quite likely we
shall), I don't really care whether you call it a bug-fix or a feature;
I'm fairly sure I'll want it to go into LTS because it'll make client
code work better with the evolving set of ciphers in use by the servers
it'll be talking to.

So let's not get hung up on classifying things as bugs or features;
let's ask what changes should go into LTS.  Changes that are
unequivocally new features shouldn't; changes which unequivocally fix
important bugs that are likely to impact many LTS users should.  The
mess in between does somewhat align with the fuzzy distinction between
bug and feature; but we shouldn't get hung up on that distinction when
deciding the real question: does this change belong in LTS ?

So a third reason why cherry-picking back to 5.6 makes sense is that
each such change does need to be studied for "does it belong in LTS";
this may at times be contentious, which shall slow down review of those
changes.  If we stuck with merging all the way, that would delay those
changes getting into more recent branches where there is less to argue
about.  Once you've got your fix into stable (and it's begun its merge
journey up the chain towards dev) you can start arguing about whether it
belongs in LTS, in a separate review for the cherry-pick.

The reason we should limit the changes in LTS to critical change is that
all change incurs risk and the point of LTS is to assure stability.  For
a critical change, the benefit (fixing a critical problem) more surely
out-weighs the (unquantifiable until too late) harm implicit in the risk
associated with change.  LTS users are - ipso facto - more conservative,
more risk-averse, so better served by a more stable (i.e. less changing)
product.

	Eddy.