[Development] Qt6 repo

[Alex Blasche]

> -----Original Message-----
> From: Development <development-bounces at qt-project.org> On Behalf Of
> Volker Hilsheimer

> > I am not asking for *support*. I am asking how to find a recent
> > working combination of Qt modules that I need for porting some code
> > base to Qt 6. Don't tell me to use 6.0 nor to wait for some 6.x.
> 
> Our CI system should prevent that a change to a dependency.yaml file merges
> that results in multiple dependencies to several conflicting versions of any
> upstream library.
> 
> If a change to qttools/dependencies.yaml file adds a dependency to
> qtdeclarative:A and qtbase:B, but qtdeclarative:A depends on qtbase:A, then
> your change won’t merge (Coin will fail during provisioning).

This is a very simplistic way and I can understand why you might think it works for you. However, the further you get in the dependency chain the more complex your chain is. You gave a nice linear dependency in your example. Imagine you have a diamond dependency (e.g. when you checkout webengine):

qtmodulefoo -> qtdeclarative -> qtbase
                        -> qtmodulebar -> qtbase

You approach does not work here. If you make a commit to foo, bar and declarative have a different dependency to qtbase you will find two chains which might be incompatible. The CI will detect it but the effort to keep every module you depend on in sync is huge the further you are away from qtbase. 


 > >> For people developing Qt, once you've checked the Git repositories
> >> out, it doesn't matter whether there's a .gitmodules or not to build.
> >
> > Lacking a monolothic repo the superrepo is currently pretty much the
> > only safe way to find a working combination of reasonably recent
> > states of Qt modules. Sure, one can try HEAD of each module first, and
> > it works sometimes. In a few more cases commenting out a few unneeded
> > bits helps to make it work, but after the third attempt one wants a safe fall
> back.
> > So far the superrepo delivers that.
> 
> 
> So does the chain of dependencies.yaml files. If the above Coin process works, it
> results in a consistent set of dependencies. The closer you are to qtbase, the
> closer to HEAD your qtbase will probably be. If you want to work on a module
> far down the dependency tree, your qtbase might be older because not all
> dependencies have been updated.

Sadly the set is not consistent. To get a build for foo I might first have to push either declarative or bar ahead first. Since the dependency of foo and declarative is set independently from each other, chances are they will always be out of sync. Especially the less active bar repo will always lack behind. As a matter of fact, even if the qtbase SHA's for foo and declarative are compatible, the scripts simple SHA checking won't detect it. 

This means a release team will face challenges finding a releasable set of SHA's across the modules. To make a decent release you have to face synchronizing SHAs in 20 git modules while a common supermodule will do this in one set. The trouble of making everything work like a qt5.git update won't disappear but is much harder because you have to deal with 20 commits across the git module. 

 
> git submodules only updates if everything works. That’s not useful if you
> primarily work on qtdeclarative, so only depend on qtbase (and yes, we want
> people working on qtdeclarative to test their changes against e.g.
> qtquickcontrols2 as well; but I hope you get my point).

*If* you work on declarative you suggestion is fine. qt5.git is not for this usecase anyway. It is for a common release. Qt5.git is not for that but for a release team or first time user who looks at a complete releasable/usable set of SHA's at a given time. One qt5.git update will do that. Your approach requires multiple checkouts across several modules behind some magic script. 

--
Alex