[Development] Proposal: New branch model

[Alex Blasche]

>From: Development <development-bounces at qt-project.org> on behalf of Edward Welbourne <edward.welbourne at qt.io>

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.

Past experience has shown that Eddy is very much correct here. Customers fix in their branch. If you have little knowledge of Qt's internals and you ask this person to fix it in a branch that is not even the one they use puts up an extremely high threshold for contributions. In fact I can recount multiple times when a fix was not suitable for LTS and I requested a patch move to dev and the response was, no time to test that outside my own use case. . Later asking them to also make cherry-picks backwards (in case of conflict), just worsens the situation. 

We want more contributions from people who have little time for their own project. This suggestion makes  is completely counter productive to people not working full time outside of Qt. 

 
>> 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.
>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 ?

I value the customer contribution more than a merge effort on my behalf to keep the repo going. As I said earlier, Liang's merge effort can be distributed and I am happy to to do that for the repo's I maintain. That's how valuable the patch from a random contributor in his context is for me. Mind you the scrutinization in dev needs to be proven first. I don't buy it when we cannot even mange to find enough reviewers for patches.

--
Alex