CI moved to Qt 6.7 for Linux builds

[Ben Cooksley]

Hi all,

I have just flipped the switch that has moved the CI system over to using
Qt 6.7 for Linux builds on our SUSE images.

Should you see any issues with builds failing as a result of packages being
missing in the registry then please submit a merge request to
sysadmin/ci-management to ensure that build dependency is added to our seed
jobs.

I'll leave the Qt 6.6 package registry and container images in place for
another week or so then will schedule them for removal.

As part of this I have also updated the list of projects with Qt 6 only
master branches. Any residual Qt 5 build artifacts the CI system was
holding for those projects have now been purged, which may impact
downstream projects that depend on those projects that are still on Qt 5.

On an adjacent note, i'd also like to schedule removing CI support for
release/23.08 and Plasma/5.27 builds (by purging all their binaries we
currently hold) for the Qt 5.15 series.

While checking however I note that several projects still have activity on
those branches. Can we please confirm whether any further releases are
expected, as i'd prefer to remove anything that isn't being properly
maintained anymore.

Thanks,
Ben

Please cleanup old forks

[Ben Cooksley]

Hi all,

As part of routine maintenance on Invent (Gitlab) i've been reviewing the
total amount of space currently being consumed by repositories.

At this time, the top 100 largest repositories on Invent (we have 14,000 or
so for context) are consuming around 21% of the total space. It would
therefore be good if we could please clean this up.

To add a bit of context, we currently have around 140GB of repositories,
and a further 30GB of pooled repository data (shared among the canonical
repository and it's forks). Those top 100 repositories currently use 30GB
of space - so as much as all of the pools.

Forks of KDevelop and docs-krita-org feature heavily on the list of large
repositories.

Of particular interest are old forks (created more than 2-3 years ago) as
these are often not participating in Gitlab's mechanism to reduce the disk
space taken by forks (known as pool repositories).

As an additional note: please do not fork a fork, as these forks-of-forks
cannot participate in a pool and must carry a full copy of the upstream
repository data. If you have a situation where a network of forks of forks
has developed please consider options to resolve this.

I know Krita at least has this situation presently with their fork of
various parts of Qt that is being maintained in people's personal
namespaces.

Thanks,
Ben