[Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Ville Voutilainen]

On 11 April 2017 at 12:14, Marc Mutz <marc.mutz at kdab.com> wrote:
> On Tuesday 11 April 2017 10:34:20 Ville Voutilainen wrote:
>> To elaborate: I run a bleeding-edge compiler. It feels odd to me that
>> the best branch to run it on
>> is a non-bleeding-edge branch, it's quite the opposite.
>
> I know GCC works differently, probably because you use a RCS that sucks at
> merging, but the Qt way was, and continues to be, to put (important) bug-fixes
> (incl. compile-fixes) into the stable branch, and merge them up. This is how
> Git works best, and apart from LTS, we strongly discourage cherry-picking. The
> problem at hand is now whether 5.8 continues to be the stable branch, even
> though no release is planned from it.

Well, the way GCC works may be due to hysterical raisins; today almost
all of its developers
use git, but it's unlikely that they would change the way they work.
Why? Because
the way things are done in GCC, trunk always gets every bug fix and
also works as the first
line of defense against regressions, and the released-branches are
less likely to
break, because not everything under the sun is pushed there. That sort
of a model
makes perfect sense to me (and I claim that's not just because I'm
used to it, I say
it *makes sense*), whereas the Qt model gets some getting used to.

You say we discourage cherry-picking. Why? Is that not a fairly
natural way to backport
bugfixes from a bleeding-edge branch to a stabler branch?