Minimum Qt for Plasma 6.3

[Ben Cooksley]

On Fri, Jan 10, 2025 at 5:26 AM Nicolas Fella <nicolas.fella at gmx.de> wrote:

> Am 09.01.25 um 17:20 schrieb Volker Krause:
> > On Donnerstag, 9. Januar 2025 11:12:09 Mitteleuropäische Normalzeit David
> > Redondo wrote:
> >> Am Mittwoch, 8. Januar 2025, 17:18 schrieb Nicolas Fella:
> >>> Am 08.01.25 um 10:57 schrieb David Redondo:
> >>>> Hi,
> >>>>
> >>>> the original plan for Plasma 6.3 was to require Qt 6.8 (as the wiki
> >>>> currently notes). However FreeBSD so far didn't gain Qt 6.7 and we
> >>>> never bumped it. The first Beta is tomorrow. So I think we just go
> with
> >>>> 6.7?
> >>>>
> >>>> David
> >>> I am rather annoyed that this is the second (at least) time we find
> >>> ourselves in this situation. Can we somehow handle this better in the
> >>> future?
> >> I agree we had the same situation with Plasma 6.1 where we wanted
> >> 6.7 but were stuck on 6.6 leading to the
> >> "6.6 (6.7 strongly recommended) " minimum.
> >>
> >> Maybe we did not communicate appropriately with sysadmin about this and
> >> our wish was not known? Or is there something else holding it back?
>

I haven't received any specific request for Qt 6.8 no, however for Qt
version bumps normally we would have completed the bump long before now so
that isn't really the issue there.
CI doesn't tend to wait too long once packaging has been completed (SUSE
for Linux, Craft for Windows/Android, etc) - however that is where FreeBSD
becomes problematic.

FreeBSD is a very unfortunate situation at the moment - as our images
depend on a custom FreeBSD repository (hosted at
https://cdn.kde.org/freebsd/) which is maintained by a single FreeBSD
packager.
I've not heard from them in a while now and have a couple of other merge
requests in sysadmin/ci-images waiting so this was always going to need
resolving.

I can't recall entirely why we have a custom repository but I believe it
relates to getting us updates (or even entirely new packages) sooner than
is possible with conventional FreeBSD repos.


> > Independent of this specific case, I don't think expecting sysadmin (ie
> > practically just Ben as far as CI is concerned) to deal with dependency
> > updates on the CI is going to scale, we need to see that as our all
> > responsibility. And since the move away from Jenkins a lot of that work
> can be
> > done without special sysadmin powers:
> > * Figure out if upstream has the new version already, and if not figure
> out
> > what's blocking that (and outside of Linux/FreeBSD upstream is also us,
> via
> > Craft).
> > * Submit MRs for the CI pieces that need updating (container images,
> Gitlab
> > template).
> > * And probably most importantly: help with dealing with the potential
> fallout
> > form the updates.
>

Volker is correct - the bulk of CI maintenance work for all our platforms
lives in sysadmin/ci-images, sysadmin/ci-utilities, sysadmin/ci-management.

Note: Qt version bumps do need a package repository setup under
teams/ci-artifacts/ so not as simple as just bumping everything all at once.
We stagger it by creating a new Docker image first, then we do the seed
builds in sysadmin/ci-management, and finally once all of that is happy we
actually transition the jobs that run in our repos over by bumping
sysadmin/ci-utilities.

This is done like this to minimize disruption as it can take a number of
hours to build all of the projects in Frameworks / Plasma / Apps that other
things depend on and if you bumped sysadmin/ci-utilities immediately then
the dependencies for your builds wouldn't be available and CI would die
until the seed jobs had gotten far enough through to satisfy your project
and it's requirements.

FreeBSD is unfortunately still much fiddlier than I'd like, as it depends
on a custom FreeBSD repository being updated first, the subsequent package
name changes that seem to accompany that being merged, and then the image
being built.
We don't have a CI approach to building images yet - mostly as Podman on
FreeBSD is still fairly new - so it relies on someone (me) logging into a
builder and manually building an image (thankfully just two commands, one
to build and one to upload)


> >
> > Regards,
> > Volker
>
> I think this particular case is mostly a FreeBSD issue, which happens to
> be where contributing to our CI setup is the least approachable for
> people on the outside.
>

Thanks,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20250110/7cc4fb51/attachment-0001.htm>