On Thu, Dec 07, 2017 at 10:28:36PM +0000, Liang Qi wrote: > 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 >
https://bugreports.qt.io/browse/QTQAINFRA-868 is much more pertinent. > — 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
