[Development] Proposal: New branch model

[Edward Welbourne]

Am 24.01.2019 um 10:20 schrieb Volker Hilsheimer:
>>>> The whole notion that my change has to become someone else’s problem
>>>> by design of the merge process is more than just a little crazy to
>>>> me. I want to own my change, have control over which branches it
>>>> hits, and be responsible for cleaning up the mess my change might
>>>> have caused. The current model doesn’t give me any of that beyond
>>>> the initial merge.

On 28 Jan 2019, at 13:27, Robert Loehning <Robert.Loehning at qt.io> wrote:
>>> That's laudable, but a non-professional developer who just submitted
>>> a fix and doesn't follow all the other changes going on might have a
>>> different opinion.

On 28 Jan 2019, at 13:36, Martin Smith <Martin.Smith at qt.io> wrote:
>> Wouldn't we expect those external patchers to submit changes to dev
>> only? Then the module maintainer, or an LTS version maintainer (is
>> there a maintainer for each LTS version?) would decide whether the
>> change should be cherrypicked into an LTS version.

Some will do as you expect.
Others will do otherwise.

A client project, using Qt, that's opted to use our last LTS will, when
it contributes fixes to Qt that have been prompted by their need to fix
a problem Qt is causing for them, will most likely contribute their fix
targeting the LTS - they're upstreaming the fix they're using locally,
in the hopes that they'll one day stop needing to maintain that fix
themselves by patching their Qt sources.  They won't know or care about
dev.

We can, of course, ask them to deliver the fix via dev, which may
require re-working it; but they'll want to know it's going to make its
way to the LTS, because that's what they care about.

Volker Hilsheimer (28 January 2019 13:54) agreed:
> Indeed; esp in the cases where a causal contribution comes in, and
> where then the maintainers need to invest time to decide whether or
> not this is material for a stable branch, dev should be the first
> branch.

It (mostly) suits *our* needs best for everything to land in dev; but
not all potential contributors have the same priorities as us.

> A change making it into dev where it can be noticed and scrutinized by
> a bunch of people that didn’t participate in the merge request, where
> it can pass additional build and configurations, and generally be
> exposed to different cases that are not covered by CI - isn’t that
> valuable?

Yes, that is valuable; so is the stability of stable branches.

Actually scrutinising each bug-fix that's going into a stable branch in
the context of that stable branch - rather than in the context of a dev
branch, from which it's cherry-picked with less scrutiny into the stable
one - makes it less likely that we'll break the stable branch.  Users
surely have stronger expectations of stability for stable branches than
for cutting-edge first releases of a later minor version.  So breakage
in dev (caused by things merged up to it) is less harmful than breakage
in stable (caused by things cherry-picked down to it).

Which of these valuable things do we prize more highly ?

	Eddy.