[Development] Proposal: New branch model

Robert Loehning Robert.Loehning at qt.io
Fri Jan 25 15:23:36 CET 2019


Am 24.01.2019 um 10:39 schrieb Volker Hilsheimer:
>> On 24 Jan 2019, at 09:22, Jaroslaw Kobus <Jaroslaw.Kobus at qt.io> wrote:
>>>> "All(**) changes would go to dev. From which they would be automatically
>>>> cherry-picked by a bot to other branches. The decision to which branch cherry-
>>>> pick, would be taken based on a tag in the commit message. We could add a
>>>> footer that marks the change risk level as in quip-5"
>>>>
>>>> No sure I understand the above correctly. Let's say in dev branch some source file got refactored completely, so that no single line match the old version anymore, e.g. Qt 5.9. Now you need to fix the old code, which is in 5.9 branch - how in this case you may try to push your fix to dev?
>>>>
>>>> Jarek
>>>>
>>> That’s where the “with exception of branch specific changes” clause (which the ** points at) kicks in.
>>>
>>> Is the fix needed in dev (or is the bug fixed by the refactoring)?
>>>
>>> If yes, then fix it in dev, and then make a separate fix in the relevant LTS branches (perhaps starting with the cherry-pick’ed change). Or just accept that this bug won’t/can’t be fixed in the pre-refactoring codebase.
>>>
>>> If no, then push the fix for the newest branch where it’s needed, from where it can be cherry picked further; don’t do anything in dev (including “don’t expect someone that knows nothing about your change to deal with the merge conflict”).
>>>
>> In this case there is additional step then. You would be forced now to check first both 5.9 and dev branches and detect if a fix would be "applyable" to the dev or not.
> 
> 
> Testing whether the bug that I’m fixing exists in dev or not is part of the drill of fixing bug, isn’t it? Why would you spend time on fixing something in 5.12 without checking whether the issue is still present in the latest codebase? Perhaps the issue has been fixed already, just without the author considering it relevant for 5.12 (perhaps for good reasons).

Why would somebody who maintains a project on Qt5 but made the decision 
to not migrate it to Qt6 care about fixing the latter?

Cheers,
Robert

>> Besides, if you decide that your fix goes only to the 5.9 branch - in this case you follow the current model anyway, right? So, having two models isn't better than having just one I think.
> 
> 
> With the proposed model there are no more automatic merges from more stable to less stable, so once my change made it into 5.9, that is it.
> 
> 
> Volker
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
> 



More information about the Development mailing list