On Fri, Jan 25, 2019 at 01:12:11PM +, 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
