[Development] Proposal: New branch model
cavendish.qi at gmail.com
Thu Jan 24 09:08:29 CET 2019
Lots of talks happened already on this thread.
I would like to think old model as "merge" model VS new model as
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
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
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
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.
More information about the Development