[Development] Qt6 repo

[Thiago Macieira]

On Thursday, 14 January 2021 06:08:43 PST Volker Hilsheimer wrote:
> > Same here. Please refrain from cooking up our own git submodule
> > replacement soup.
> 
> Hm, but dependencies.yaml already *is* our own “git submodule replacement
> soup”, to some degree, isn’t it?

Not if I don't care about the dependency. If I am making a change to a given 
module, I *must* test its tip. Moreover, I should expect that the dependency 
on other modules has moved by the time my change gets tested in the CI, so I 
should also be testing against the dependencies' branch tips.

The dependency.yaml file is good for the CI so it doesn't introduce breakages 
in leaf modules until they get fixed. But for *development*, it isn't useful. 
It's actually detrimental.
 
> Nevertheless, federating the declaration of the dependencies across modules
> out to each module is the right idea, I think. It's tradeoff is between
> (eventual) consistency that allows us to declare a release that includes
> all packages, and not making a centralized .gitmodules file the bottleneck.
> The 5 step process that required the qt5.git integrations to succeed twice
> to make trivial changes in private APIs that were used across modules, is
> not something I think we want back either.

We should stop using private APIs to this extent.

If some module needs private API and is not a tight integration like QML is to 
QObject, that's a red flag that the API should be public in the first place.

(QObjectPrivate inheritance is usually source-compatible)
 
> Take away: .gitmodules and dependencies.yaml can and need to coexist.
> Neither will work for everybody.

I actually agree.
 
> The only problem that remains is that the top-level build system lives in
> the super module, forcing people that want to use that build system
> together with worktrees to hack around the mess. If we can solve that by
> moving the build system out as part of establishing a qt6.git or whatever
> we end up with, then I’m a happy camper.

The top-level buildsystem is optional. If it can be replaced by a single small 
CMakeLists.txt or a shell script or hand-written Makefile, we should do it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering