Lots of talks happened already on this thread. I would like to think old model as "merge" model VS new model as "cherry-pick" model.
In the old "merge" model, normally we will drop a branch out to cherry-pick mode after having more than 3 branches and try to have 2 branches(change LTS branch to cherry-pick mode after a while). The worst case is when we have 5.12/5.13/dev branches with regular 5.12->5.13->dev merges, and also 5.12.x and 5.13.y release branches, more merges involved. You can imagine the "chaos" when a critical fix is needed for multiple branches, especially the delay for development in dev branch. In this scenario, I will trigger a qt5 integration(with latest sha1 from all submodules) in 5.12, it will take about 1 day(at least 8 hours, a work day) to see whether it is broken or not. After fix everything in 5.12, I will try 5.13, same process, and dev. The whole round is quite painful, especially around feature frozen period, if some API changes happened, more ping-pong rounds are involved, more details see https://lists.qt-project.org/pipermail/development/2016-October/055084.html (old url was invalid any more, after the mailing list scripts regenerated the web pages.) From last year(2018), I had a merge script/bot (https://codereview.qt-project.org/#/q/owner:%22Qt+Forward+Merge+Bot%22,n,z) to do the merge work, it checks qtbase and qtdeclarative daily, and do merge if more than 5 new changes happened. And check other modules twice a week, and do merge if there is new change old than 1 week. BTW, qtwebengine is a bit special, and some module maintainers(like J-P for qtquickcontrols2) triggered the merge regularly by themselves. With merge model, and the bot, this situation also happened regularly. Like my current attempt to have a qt5 5.12->dev merge plus a qt5 dev submodule update, * https://codereview.qt-project.org/#/c/249863/ * https://codereview.qt-project.org/#/c/250191/ * https://bugreports.qt.io/browse/QTBUG-72953 * https://bugreports.qt.io/browse/QTBUG-73224 Both related with changes in qtdeclarative 5.12(one is a fix for QTBUG-72953, another is the source of QTBUG-73224), but a 5.12->dev merge will bring them together to dev, I need to wait for a totally fixed 5.12 for current qt5 dev integration, including fix in qtwebengine and other modules. The current estimated time is 3 days or a week. In the "cherry-pick" model, we can think every other branches than dev are in locked mode, controlled by release team or module maintainers. The developers of patches will not be involved if "cherry-pick" bot doesn't find conflicts and CI/COIN approved it. The amount of total conflicts will be same in both models. The difference is who is reponsible to fix it. I am the center point to fix them currently, but it's very difficult to know the situation in different branches in the whole qt5 umbrella. With new cherry-pick mode, the owner of the change will be notified if conflicts happened. I suggest it should also notify the module maintainer and release team. Those people are more responsible than anyone else to have the change happened in the target branches. And it will not block the development in dev. In new model, perhaps a merge monkey is not needed any more, but a cherry-pick monkey will happen. And with the direct help from the owner of the change, and not blocking dev branch, I consider it as less pressure personally. My concern is about "cherry-pick" a series of changes for a big feature, especially during the period to have "dev" branches for both 5 and 6. I don't have solution for this issue yet. Best regards, Liang _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
