> On 14 Jan 2021, at 16:12, Thiago Macieira <thiago.macie...@intel.com> wrote: > > 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.
Indeed, always work on the tip of the module you make changes in. But that doesn’t mean that you have to work on the tip of all the modules it depends on as well. Although I’m a very much in favour of doing so as much as possible. I always try to work with HEAD of everything, in the dev branch, and it works most of the time these days. It very frequently didn’t work during Qt 6 development, with both builds and behavior breakages. But I’d rather have us know about those breakages early and make it a priority to fix them, because at some point someone will have to fix them anyway. So the sooner, the better - for a complex system, mean time to recovery is MUCH more important than mean time between failure. But sometimes it’s not feasible; there might be no point in waiting for hours or days until someone else’s fix is ready. Then being able to go quickly back to the qtbase or qtdeclarative revision that e.g. qtquickcontrols2 was last successfully tested with is useful, and that’s what a check-out based on dependencies.yaml allows me to do. >> 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) It’s an ideal state that we are very far away from, I think. Perhaps another way to look at it is: IF we have tight integrations across modules on private API level, then they should be in the same repository (qtdeclarative and qtquickcontrols2 might be a candidate for that consideration)? But it’s not just APIs anyway, compile breakages would at least be easy to discover locally so that the follow-up changes to leaf modules can be ready. Behavior changes like the event refactoring we did for Qt 6 are much more messy, because so much of our tests can’t be meaningfully run on a local workstation, esp across platforms. >> 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. It’s all that already, just in the wrong place (for me and my love of worktrees) :) Cheers, Volker _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
