[Development] Qt6 repo

[Volker Hilsheimer]

> On 13 Jan 2021, at 15:22, Edward Welbourne <edward.welbourne at qt.io> wrote:
> 
> Volker Hilsheimer (13 January 2021 14:37) wrote:
>> Let me make a more radical proposal:
>> 
>> The information about which modules depend on which others modules
>> lives in each module’s dependency.yaml file. This information includes
>> the sha1 of the modules it has last been successfully tested against.
>> 
>> This information is (inconsistently) duplicated in .gitmodules. So
>> proposal:
>> 
>> * stop using git submodules
>> 
>> Using them serves no real purposes anymore. We anyway have our own
>> scripting in form of init-repository to avoid that people have to deal
>> with that stuff.
> 
> Little detail: init-repository relies on the .gitmodules file and uses
> git submodule.  So eliminating git submodule in favour of a script that
> depends on it isn't an option.

The point I’m apparently failing to make is: we already have a script today that helps people check things out.

So, we could just as well have a script that uses the information in dependencies.yaml instead.


> In particular, qt5/.gitmodules contains information about module status,
> whether each is essential, deprecated, in preview, an addon or to be
> ignored.  My scripts to generate the api change reviews use this
> information to identify which modules are candidates for such a review.
> So it's not just init-repository (which does also use status info).
> 
> Not that this argues against more flexible tooling that relegates the
> super-module-based structure to the background, but we do still need the
> information presently contained in .gitmodules, although perhaps it's
> time to eliminate its dependency information in favour of the YAML
> config files.
> 
> We could, of course, move the information presently in .gitmodules into
> some other file within each module (possibly unifying this with what's
> presently in sync.profile and dependencies.yaml), if you're OK with
> rewriting init-repository (ideally in python3) as part of your plan.

Yes, that meta-data can live anywhere, using .gitmodules is of course convenient as long as we use git submodules, and as I said, for release and packaging purposes (which API review falls under in my mind), having a super-repo might make sense.

For working on Qt, the only information we need is “which modules need to be cloned so that it’s possible to build module X from source”. That information is available, once we have module X cloned, as we can walk the dependencies.yaml data to find out what else is needed. Configure could in principle do that, it already checks whether dependencies are missing.

Volker