[Development] Qt modules, API changes and Qt 6

[Robin Burchell]

On Wed, Jan 30, 2019, at 9:17 AM, Alex Blasche wrote:
> I am clearly missing something here. Could you please outline why such a 
> monolithic repo would be good? As you pointed out yourself, the 
> conceptual problem that different libraries won't walk in lockstep 
> remains and segmented builds continue to be desired. Sure, repo checkout 
> is easier but as long as segmentation exists I fail to see the 
> advantage.

Split repositories have a lot of problems, both social, and technical, but I'd say that it all boils down to extra friction.

On the technical side, you have the well-known problem of API changes. When you make one, you have to make it in a backwards-compatible way, integrate that into qt5, then change everything, integrate that into qt5, then remove the backwards compatibility.

That's a long process, even if everything goes perfectly (reviews are easy, happen quickly, CI isn't flaky, etc, etc).

Then you have the social side of it. Basically, I think I can summarize it as being this: a repository boundary generally makes a problem into "someone else's problem" rather than "my problem" or "our problem", because the perception is it's easier that way, even if the cohesive whole ends up suffering as a result.

I will admit that a monorepo has a _different_ set of problems (including but not limited to: longer build times, longer test times, flaky tests in unrelated areas blocking changes), but those problems are not complex, and can be fixed with some dedicated application of smarter scripting at build/test time (for instance: if change is doc only, don't run any test that _isn't_ related to documentation, to cover one complaint from earlier in this thread).

I don't think that changing the technology behind how we contribute today would necessarily fix any of this split repo stuff either, I think a lot of it is just inherent to how such a system works. For instance, a project I am currently working on uses a completely different toolset, yet suffered from (a version of) exactly the problems outlined here -- and once we realised just how hard that was making life, and merged a bunch of repositories together, suddenly, things became a lot easier.

The repository merge, in our case, helped to inspire actually applying work to _fix_ those problems rather than just working around them by splitting things into smaller pieces, too.

Another real life anecdote: when I merged together our bunch of repositories, I was annoyed by ~20 minute clean build times of one component in our CI pipeline. I found out that it was due to heavy (ab)use of templates, which I managed to work around in a largely source-compatible way, and dropped the build time of that component down to ~3 minutes, which certainly made the people working on that component happy. I wouldn't have done it without the repository merge, partly because it wasn't "my problem" before, and partly because I just didn't notice, as I didn't work on that component: I still don't, really, but because I live near it, I see the code in grep results. I see the impact it has on build/test times, and so on.

Robin