[Development] Proposal: New branch model

[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).


> 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