Re: Re: Re: Decommissioning Qt 5 CI

Am Donnerstag, 30. Juli 2026, 20:53 schrieb Ben Cooksley:
> On Fri, Jul 31, 2026 at 3:47=E2=80=AFAM David Redondo <kde@david-redondo.=
de> wrote:
>=20
> > Am Donnerstag, 30. Juli 2026, 17:22 schrieb Ingo Kl=C3=B6cker:
> > > On Dienstag, 28. Juli 2026 23:36:20 Mitteleurop=C3=A4ische Sommerzeit=
 Albert
> > Astals
> > > Cid wrote:
> > > > El dimarts, 28 de juliol del 2026, a les 13:20:56 (Hora d=E2=80=99e=
stiu
> > d=E2=80=99Europa
> > > > central), Nicolas Fella va escriure:
> > > > > That said, we have a number of (Plasma) components that we still
> > build
> > > > > for Qt5 for (external) application compatibility (breeze,
> > > > > plasma-integration, etc). So far we have not made a decision to s=
top
> > > > > doing that, and I'd rather not lose CI for those. That doesn't me=
an
> > we
> > > > > need Qt5 CI in the current form. Could we use a distribution image
> > with
> > > > > Qt and the few necessary libraries/frameworks baked in? That would
> > be a
> > > > > much smaller image and easier to maintain than the current suse-
qt515
> > > > > image.
> > > >
> > > > Does the code of those repos change in qt5 related areas?
> > > >
> > > > Trying to understand what we want CI for here:
> > > >  * Potentially new qt5 code builds with old qt5/gcc distros?
> > > >  * Non changing qt5 code builds new gcc/stuff from distros?
> > >
> > > Additionally to Albert's questions I don't understand why distros that
> > still
> > > need Qt 5 builds of breeze and plasma-integration cannot simply build
> > the
> > > latest released versions that support(ed) Qt 5. Why do they need the
> > latest
> > > and greatest breeze and plasma-integration for the remaining Qt 5 apps
> > which
> > > probably haven't seen a release in years? Does plasma-integration need
> > to
> > > match the version of Plasma?
> > >
> > > Regards,
> > > Ingo
> > >
> > We did this with Plasma 5 and Qt 4 things.
> > For Plasma 6 we decided that we want applications to look and behave the
> > same
> > no matter if they use Qt 5 and Qt6. To the user Qt5 vs. Qt6 makes no
> > difference
> > and they would be confused or file a bug if some applications randomly
> > look and
> > behave differently.
> > For example single click vs. double click which was changed in Plasma 6=
=2E0
> > or breeze which received user visible changes since 6.0.
> >
>=20
> So the Plasma developers want to keep supporting Qt 5 for essentially
> eternity and never drop support for it?
>=20
> At what point do you stop, or do you just keep continuing to maintain
> compatibility because one distribution doesn't want to drop
> $unmaintainedQt5App?

(readding dropped lists)

I dont't know the concrete point in time  but  given that there are some bi=
g=20
applications on still on Qt5 I would say it's too early now.

Btw Plasma 5 dropped support of Qt4 builds of breeze and oxygen  in 2020 wi=
th=20
5.18, see
https://mail.kde.org/pipermail/plasma-devel/2020-January/108585.html

I don't think we need an image provided by sysadmin and build kf5 on our CI
infra. Couldn't we just download a image of $LTS distro like okular does?

https://invent.kde.org/graphics/okular/-/blob/master/.gitlab-ci.yml?
ref_type=3Dheads#L24

> Will Plasma developers keep Qt 5 installed on their local machines and
> perform appropriate testing for that with the legacy, unported applicatio=
ns
> still using Qt 5?
> Just having CI compile something isn't a true test as to whether it works
> or not and risks silent bitrot taking place due to behaviour differences
> between Qt 5 and Qt 6.
>=20
>=20
> >
> > Cheers,
> > David
> >
> >
> Regards,
> Ben
>=20