[Development] Proposal: New branch model

[Kari Oikarinen]

On 24.1.2019 11.11, Volker Hilsheimer wrote:
> 
> 
>> On 23 Jan 2019, at 22:09, Allan Sandfeld Jensen <kde at carewolf.com 
>> <mailto:kde at carewolf.com>> wrote:
>>
>> On Mittwoch, 23. Januar 2019 21:42:35 CET Edward Welbourne wrote:
>>> Jedrzej Nowacki wrote:
>>>>> Advantages:
>>>>> - no waiting for merges, a fix can be used right away after
>>>>>
>>>>>   integration
>>>>>
>>>>> - faster propagation of fixes targeting all branches, as there are
>>>>>
>>>>>   no merges of merges
>>>
>>> Alex Blasche (23 January 2019 18:09)
>>>
>>>> This is pure speculation because you potentially triple (or worse) the
>>>> amount of individual patches requiring a merge in gerrit when you
>>>> consider that you want to at least merge to 5.9, 512, dev and qt6. I
>>>> don't see this prediction come true.
>>>
>>> Well, as soon as it hits dev, the patch is cherry-picked to every branch
>>> that its footer says it belongs in.  Those branches where all goes well
>>> see it one integration later.  Each branch that has a conflict needs
>>> that resolved before we get to that second integrtion.  Contrast this
>>> with a 5.12 -> 5.13 -> dev chain of merges, where dev doesn't get the
>>> change that landed in 5.12 (even if that change could land in dev
>>> without conflict) until
>>> * there's been some delay between their change being accepted in 5.12
>>>   and the next merge-bot run
>>> * everyone who made change to 5.12 that conflicted on merging to 5.13
>>>   has advised Liang on how to resolve their conflicts
>>> * we've got the result through integration into 5.13
>>> * everyone who's made changes to 5.13 or (as possibly just amended in
>>>   merging) 5.12 that conflicts with anything in dev has again advised
>>>   how to resolve their conflicts
>>> * and we've got the result through a second integration, into dev.
>>>
>>> When nothing but the change being considered has a conflict along
>>> the way, that's twice as long; and any change to an upstream branch,
>>> that does have a conflict, introduces delay for all the other changes
>>> that landed in that branch, even if they don't have conflicts.  In the
>>> middle of summer, when lots of folk are away on holiday, getting help
>>> with resolving conflicts isn't easy - the folk who know those commits
>>> won't be back for a month - and all changes, no matter how urgent, get
>>> stuck behind any conflict we can't work out how to resolve.
>>>
>>> So no, Jedrzej's claim is not *pure* speculation; it's at least quite a
>>> lot adulterated with reasons to believe that many changes would, under
>>> his scheme, propagate to all branches they're destined for sooner than
>>> happens with our present scheme.
>>>
>> No, it is speculation, and it optimizing the least important case: bug-fixes
>> in dev. Dev is the branch that can wait the longest to get a bug-fix, the
>> stable branch is the branch that need it the most urgent. And fixing a bug in
>> 5.12 now means you first fix it where you need it (5.12), then rewrite it for
>> dev, then resolve the inevitable conflict back so it can be merged, all
>> waiting for bots and release teams to stumple into the issues and delaying the
>> next 5.12.x release.
>>
>> ‘Allan
> 
> 
> More people working and building against dev helps keep dev more stable (by 
> virtue of discovering breakage sooner), and the proposal encourages more people 
> to work on dev. That can be a good thing.

Our users use our releases. Our development process should aim at producing good
releases (at scheduled times). This proposal is putting more focus on dev, but
will it lead to better quality releases? Users won't care about a dev branch
that gets fixes sooner, if they have to wait for those important fixes longer
than in the current situation.

> 
> Urgency to get fixes into a stable branch is an argument that has come up a few 
> times. The current 5.12.1 release seems to be delayed because some changes made 
> it into 5.12 that shouldn’t have been there in the first place (given the 
> definition of “stable”). It would be interesting to see some data about how many 
> point releases we had to delay because “highly desirable fix for old bug was 
> stuck in the process” vs “regression was introduced in a stable branch and only 
> discovered during release testing”.

The absolute path changes got into 5.12.1 due to an explicit wish to have them
in a fresh LTS branch early. Reviewers accepted that and could have done so
under both models as easily.

The argument that these changes help by reducing changes in stable branches is
that currently people are putting in changes that don't belong there. Making
getting changes into stable branches more painful with the new model will lead
to less changes getting in. This will happen due to people avoiding work they
can avoid.

Importantly this is not the same thing as more careful consideration about
whether a change *should* go to the stable branch. The changes will be selected
based on how persistent people are, not on how important their changes are.

I assume you and other people who support the proposal think these will be very
correlated and thus improve the selection process for changes landing into
stable branches. I'm not convinced so and instead I'm more afraid of the
opposite of missing fixes that degrade the quality of our releases.

-- 
Kari