On Monday, September 4, 2017 11:58:13 AM CEST Thiago Macieira wrote: > > True, but we can re-evaluate if it is not working, modularization is > > harder > > in general as it requires some code changes. Regarding the "two weeks" > > delay, it is mostly a social problem, as we can not agree on how often qt5 > > submodule update should happen, the status quo is kept and it happens > > randomly and on a request. > > It's usually one week for someone to go and start the merge. And then one > more week to get that past the CI.
There is a difference between merge and submodule update. If you do not work against different branches, a submodule update is enough and that one may be quite cheap. Again, it is a social issue, technically there is no problem in updating just one module in Qt5. Depending on the module, cost of it is; zero (leaf modules) to full Qt5 buid and test (qtbase), but currently we prefer to update all of them and that triggers full rebuild and test (currently we are reaching the target of 4.5h per qt5 integration, so assuming no failures it is not that bad). In addition you do not need to wait for someone to create a submodule update, it is quite easy operation. Just make a commit with a new sha1. <opinion level = "very personal"> We should do merges and submodule updates automatically, as often as possible (yes, even few times per day). Yes, it will pollute git log with "Update" and "Merge" commits, but I can not force myself to care about it (btw. it may be solvable for qt5 repo, but it would require a shadow copy and a direct push). </opinion> Cheers, Jędrek _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
