[Development] atomic commits across submodules (was: Suggestion to add labels when changing API)

[Jędrzej Nowacki]

On czwartek, 7 grudnia 2017 12:17:16 CET Adam Treat wrote:
> Hi,
> 
> 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 
aspects.

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:
> 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?
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 functions.

Cheers,
  Jędrek