[Development] Proposal: New branch model

[Robert Loehning]

Am 28.01.2019 um 13:54 schrieb Volker Hilsheimer:
>> On 28 Jan 2019, at 13:36, Martin Smith <Martin.Smith at qt.io> wrote:
>>> On 28 Jan 2019, at 13:27, Robert Loehning <Robert.Loehning at qt.io> wrote:
>>>> Am 24.01.2019 um 10:20 schrieb Volker Hilsheimer:
>>>>> On 24 Jan 2019, at 08:03, Olivier Goffart <olivier at woboq.com> wrote:
>>>>> [...]>    - Stay with the current solution <= the merge effort is too big and qt6 is
>>>>>> expected to cause conflicts that really should not be solved by one person
>>>>>
>>>>> Again, I don't see how the proposed model reduce the amount of conflicts.
>>>>> If the "one person" is the problem, then nothing prevents you to assign more people to the job. One easy way is already to share the different modules (repositories). But with some cooperation it is also possible to share the work accross directories, or by number of commits. One can also be pragmatic and revert most problematic commit (that fails tests) in dev or stable, then let the author work at it again.
>>>>
>>>> Having to wait for someone else to trigger the merge and resolve the various conflicts before I can continue to base my work on dev on a fix that I already made in 5.12 breaks flow. Distributing this work to more people doesn’t solve the problem.
>>>>
>>>> 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.
>>>
>>> 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.
>>>
> 
>> 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.
>>
>> martin
> 
> 
> 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.

In the new model, dev should always be the first branch. Would we then 
have some changes for which picking and resolving conflicts is expected 
to be done by the author, some for which it is expected to be done by 
the maintainers and a gray area between those?

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