Am 24.01.2019 um 10:39 schrieb Volker Hilsheimer: >> On 24 Jan 2019, at 09:22, Jaroslaw Kobus <jaroslaw.ko...@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@qt-project.org > https://lists.qt-project.org/listinfo/development > _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
