[Development] Qt modules, API changes and Qt 6

[Frederik Gladhorn]

Here are the options we discussed internally. I'm happy to elaborate more in 
case something is unclear.


1 Do nothing / today / qt5.git

2 Heads: use the latest revision of each branch (the system we used to have in 
the past)

3 Modules containing pinned dependency sha1s
        Each module is completely self-contained, that means qt5 is not 
required as such (but may still exist as a collection of all modules, for 
convenience and releases). In each module we have a list of dependencies and 
their sha1.
        Updates for a release (and also otherwise) must happen regularly (e.g. 
nightly), moving each module forward towards newer dependencies, this would be 
implemented as bot which updates the above mentioned requirements file.

4 Monolithic repository for essentials
        Merging at least qtbase and qtdeclarative and probably a whole lot 
more into one repository. Likely excluding webengine and webkit.

5 A way to stage breaking changes across modules (updating for example qtbase, 
qtdeclarative and qt5.git at the same time)
        Presumably do some annotation of the commit message in Gerrit, or 
figure out how to connect changes in Gerrit in another way.



I made a small table on the wiki:
https://wiki.qt.io/Qt6_Enabling_API_Changes



Some notes:

1: is where we are today and in my opinion our processes get in our ways

2: we used to have this, it has the problem that some modules are always 
failing tests due to their dependencies changing. That's an unfortunate 
situation. We want to find out about breakages due to dependencies quickly but 
don't want to block development.

3: All modules get the same treatment and it makes things more consistent. At 
the same time we really need a bot then that moves modules forward with 
respect to their dependencies. We would also want to have a visualization that 
shows how much a module is behind e.g. qtbase (in days and number of commits).
We almost had this before in the form of sync.profile where pinning was an 
option.
This proposal does the pinning always and will result in a lot of commits that 
simply say: bump dependency versions.

4: Requires finding out how to run the CI on this. It's in many ways 
attractive, but we would always struggle with defining what's in and what not. 
I see Qt also as ecosystem where modules join and sometimes get left behind. 
We want to enable that more, so the mono repo approach seems tricky in that 
respect. That doesn't prevent deciding on some repos being merged. Merging 
between Qt 5 and 6 will then be harder though.

5: This is more of a cludge and could allow staging changes in qtbase and 
qtdeclarative at the same time while also trying to update qt5.git. It's a bit 
complex and needs people to be very aware of it and will block other changes 
from being processed at the same time.



Cheers,
Frederik