[Development] Qt6 repo

Volker Hilsheimer volker.hilsheimer at qt.io
Fri Jan 15 11:19:56 CET 2021

> On 14 Jan 2021, at 23:23, Oswald Buddenhagen <oswald.buddenhagen at gmx.de> wrote:
> On Thu, Jan 14, 2021 at 02:08:43PM +0000, Volker Hilsheimer wrote:
>> Nevertheless, federating the declaration of the dependencies across modules out to each module is the right idea, I think.
> no, it's not. for tightly bound co-evolving packages, the vcs should provide as much atomicity as reasonably possible.
>> 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.
> you're setting up a false dichotomy. i've described how to do it properly with only .gitmodules before the .yaml crap went into full production, but tqtc was (as usual) more interested in protecting a prior investment than doing things right.

Hey Ossi,

I must have missed that. Could you share your idea again, it sounds great.

FWIW, I know it’s popular to blame The Qt Company for all sorts of things right now, but as I remember the discussion around dependencies.yaml, it was not driven by The Company at all, but by senior members and maintainers of the Qt community (some of which happened to be TQtC-employees at the time).

> and yes, it *is* crap. run gitk --all in any non-central module and tell me with a straight face that what you're seeing doesn't suck big time.  yes, as the maintainer of qttranslations i have to deal with that on a (somewhat) regular basis.

Since I’m on macOS I don’t use (or have) “gitk” or any equivalent tool, and even if I could “brew install” it, I probably won't care as much for the aesthetics of the visualised git history as you do. So, I’ll trust you that it sucks big time.

I would still like to understand how that particular suckfulness impacts the life and work of a maintainer of one of the submodules though.


More information about the Development mailing list