I really don’t think switch back to a monolithic repo is a good idea… But if I understand atomic commits across submodules as successful integrations in qt5, I think it has some meaning to me. Here are a few tasks which I think perhaps related with this topic.
https://bugreports.qt.io/browse/QTBUG-19580 https://bugreports.qt.io/browse/QTQAINFRA-824 — Liang > On 7 Dec 2017, at 18:17, Adam Treat <[email protected]> wrote: > > Hi, > > I think it is high time that we fix the underlying problem: supporting atomic > commits across submodules. > > Once this is done we should revert our CI to test changes against latest > version of all modules. As for how this could be done: > > * Adopt something like Google's repo tool: > https://code.google.com/archive/p/git-repo/ > * Stop using submodules and use a monolithic repo > * Git subtree > * Implement atomic commit across submodules not in Git, but in the > gerrit/COIN layer so that COIN effectively locks integrations until commits > that span submodules are finished > * Something else? > > Cheers, > Adam > > On 12/07/2017 11:22 AM, Liang Qi wrote: >> Since >> http://lists.qt-project.org/pipermail/development/2016-October/027542.html , >> Coin tests all changes against Qt5 instead of the latest version of all >> modules. >> >> The situation is sth like, some new APIs were added to qtbase in 5.10, and >> other modules were adapted. But around beta or sometime(before release), >> some refactoring work happened on those APIs. We adjusted them in qtbase, >> and other modules. We have several steps to make sure those thing to be >> approved in CI/COIN. But the order of things gets lost easily when merging >> the changes up, for example to the dev branch. >> >> Here are some suggestions to make those steps more clearer to the people who >> maintain merge and integration. >> >> The changes that are important to be merged up before other changes should >> have a special tag, such as API_CHANGE in the commit message. Then the >> script used to do the merges could stop and/or warn about commits with this >> tag in the message, which would make the merge easier. We can also apply >> this check into the submodule update script. >> >> The situation is also valid for some private API changes(which were used >> cross qt submodules). >> >> About which labels are better to be used for this purpose, please give your >> suggestion and votes. Thanks. >> >> Best Regards, >> Liang >> >> _______________________________________________ >> Development mailing list >> [email protected] >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
