[Development] atomic commits across submodules (was: Suggestion to add labels when changing API)
jedrzej.nowacki at qt.io
Mon Dec 18 11:24:18 CET 2017
On czwartek, 7 grudnia 2017 12:17:16 CET Adam Treat wrote:
> I think it is high time that we fix the underlying problem: supporting
> atomic commits across submodules.
As I'm not against the idea, I'm not really fan of it either. The problem with
atomic commits across submodules is that they encourage API breakages. Without
supporting both code paths even for a little while, one is not aware of the
pain that our users needs to go through every time we break API.
Even private API modifications have side effects. If you are working in qtbase
then it is easy, but otherwise you are forced to recompile quite often or risk
debugging subtle binary incompatibilities. It is not as crazy as during qt5.0
but still happens.
In addition we were thinking about splitting submodules even more. Reduce
amount of private API usage or even make them use only public API (quite nice
but a controversial dream, please do not start discussion about that now :-)
). Make them more independent libraries, which would have many positive
If you keep all these in mind, cross sumodule modifications are not encouraged
and our process was never optimized for the case. Just to be very clear if you
want to simplify changing many submodules at once, then you would get my full
support, but keep in mind that it should not be disruptive nor for other Qt
developers nor for Qt users.
> Once this is done we should revert our CI to test changes against latest
> version of all modules.
No. First, how these two are connected, that is a big jump to a solution,
without providing reasoning. I know that you didn't know about the fact that
we pin submodules in qt5 and you got burned by this. That __is__ an argument,
but an alternative solution would be a better documentation or UI. Second,
the most important, that doesn't scale. By compiling against latest Qt5 we
reduced CI load by ~80%.
> * Adopt something like Google's repo tool:
> * 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?
I think there is nothing in our infrastructure that would block us from
implementing atomic cross submodules commits. It is matter of Coin calling few
More information about the Development