[Development] Proposal: New branch model

Martin Smith Martin.Smith at qt.io
Mon Jan 28 13:36:28 CET 2019


>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

________________________________________
From: Development <development-bounces at qt-project.org> on behalf of Robert Loehning <Robert.Loehning at qt.io>
Sent: Monday, January 28, 2019 1:27:20 PM
To: Volker Hilsheimer
Cc: Qt development mailing list
Subject: Re: [Development] Proposal: New branch model

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.

Cheers,
Robert


--
   Robert Löhning, Software Engineer - The Qt Company GmbH
   The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
   Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
   Sitz der Gesellschaft: Berlin,
   Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
_______________________________________________
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development



More information about the Development mailing list