On Fri, Jan 25, 2019 at 01:12:11PM +0000, Frederik Gladhorn wrote: > qt5.git serves several purposes today, for example: > - it contains a few binaries needed for Windows development > that's rather trivial, and the only reason i didn't fix it years ago is that factoring these out to another repo would cause everyone cloning *two* instances of somewhat big-ish stuff they probably don't need. if we accept that accurate historical checkouts of these binaries are irrelevant, it would be possible to permanently excise them via git object replacement nowadays.
> - it gives a definition of which modules make up a Qt release > - it collects sets of revisions which work together (because they were tested > with each other) > - it has a bit of build system infrastructure to build all of this > > In my opinion there are a few issues with what we have: > - updating qt5.git (and thus making releases) is cumbersome > - it's unclear for many people what a module is tested against in the CI > (its dependencies are checked out at the revisions specified in qt5.git, > not > the latest revisions of the corresponding branch) > > [and some other spread out mentions of related issues] > https://bugreports.qt.io/browse/QTQAINFRA-868 > - we have more products, such as Qt for Automotive, Automation, Device > Creation, should those have qt5-special-purpose repositories? > no. these somewhat arbitrarily defined products don't need to be reflected in the supermodule itself. > - modules outside of qt5.git get different treatment, making it hard > to include new modules > the solution to that is simple: don't have "proper" qt modules outside qt5. the only reason for the current situation is an irrational fear of the kde free qt foundation, because, gee, referencing a repo from a git supermodule is *just* the same as "marketing it as part of qt". for private modules, a private branch of qt5 can be maintained (in the qt5 shadow repo; it can't be in the main one due to gerrit "limitations"). big "leaf" modules which intend to be separate products with independent release cycles (e.g., qtwebkit and qtwebengine) can/should live outside the super repo, because the advantages of detaching them outweigh the additional bother this causes. > Modules are not self-contained (since the fine-grained dependencies > are specified in qt5.git). We don't know how to cleanly handle > dependencies for modules outside. > the current structure is optimized for init-repository, which vastly simplifies the life of developers and is also taken advantage of by the CI system. if you want to move away from a simple supermodule, you'll need a complex meta structure instead. you'll need to extract the dependencies from the repositories (hey, a sanely machine readable build system would have helped with that - too bad the idea was abandoned) and centralize them in a living document which is fetched by whatever checkout script you come up with. you can get some inspiration from kde. you can expect opposition to _requiring_ additional scripts to just get a workable checkout. and google is moving away from "repo" in favor of git native functionality. note that atomic versioning of the dependencies (which is something you need if you expect bisect to be actually useful) is totally impractical to implement with only in-module dependencies. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development