[Development] Proposal: New branch model

Volker Hilsheimer volker.hilsheimer at qt.io
Mon Jan 28 14:17:09 CET 2019


> On 28 Jan 2019, at 14:03, Robert Loehning <Robert.Loehning at qt.io> wrote:
> 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?

I think “it depends”, and it’ll be a matter of negotiation. The worst case scenario in case of cherry-pick-conflict is “we couldn’t agree on whether it should go into stable, or we couldn’t find anyone to port it back, so it’ll only be in the next minor release”. That’s not such a terrible "worst case”, I think.

Making the merge into dev independent of that discussion at least keeps things moving forward. If then the author doesn’t want to spend time on backporting and conflict resolving, but there are lots of users and customers asking for the fix, then that’s a matter of finding someone else to pick up the challenge.


Of course, doing it like what Jędrek (IIRC) reported from the Python community and leaving it to the maintainers to take things down into stable branches is one way. Then maintainers have control over the order and timing, and can perhaps avoid a lot of mess that way.


Volker



More information about the Development mailing list