Re: Decommissioning Qt 5 CI

Nicolas Fella <[email protected]> Wed, 29 Jul 2026 12:07:15 +0200
Newsgroups gmane.comp.kde.devel.general,gmane.comp.kde.devel.plasma,gmane.comp.kde.devel.core,gmane.comp.kde.releases
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--------------FiNYtJgpSXSF2wJxeCjJWxnz
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 29/07/2026 12:00, Ben Cooksley wrote:
> On Wed, Jul 29, 2026 at 7:31=E2=80=AFPM David Redondo <kde@david-redondo=
.de>=20
> wrote:
>
>     Am Dienstag, 28. Juli 2026, 23:36 schrieb Albert Astals Cid:
>     > El dimarts, 28 de juliol del 2026, a les 13:20:56 (Hora d=E2=80=99=
estiu
>     d=E2=80=99Europa
>     > central), Nicolas Fella va escriure:
>     > > On 28/07/2026 12:52, Ben Cooksley wrote:
>     > > > Hi all,
>     > > >
>     > > > For some time now Qt 5 has been in extended maintenance /
>     support,
>     > > > which Iif my understanding is correct has now come to an end.
>     > > >
>     > > > Accordingly, given that all of our applications have now had a
>     > > > substantial amount of time to migrate, and plenty of notice
>     that CI
>     > > > would be withdrawn eventually, i'd like to proceed with
>     withdrawing CI
>     > > > support for Qt 5.
>     > > >
>     > > > This will free up valuable space on the CI nodes and allow us =
to
>     > > > remove an image that is under very minimal, if any, maintenanc=
e.
>     > > >
>     > > > Please let me know if there are any objections.
>     > >
>     > > Hi,
>     > >
>     > > for applications I agree to drop Qt5 CI. The few usages that
>     are left
>     > > either already have Qt6 CI, or are more or less dead projects.
>     > >
>     > > 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 stop
>     > > doing that, and I'd rather not lose CI for those. That doesn't
>     mean 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:
>     >=C2=A0 * Potentially new qt5 code builds with old qt5/gcc distros?
>     >=C2=A0 * Non changing qt5 code builds new gcc/stuff from distros?
>     >
>
>     breeze, oxygen and plasma-integration is
>     * new qt5 code builds on current distros
>     it changes as the qt6 code changes. The goal is that qt5 and qt6
>     applications
>     look and feel the same.
>     For breeze and oxygen the same code base is compiled twice, once
>     with qt6 and once with qt5.
>     plasma-integration has copies of the code for qt5 and qt6 because
>     the ifdef'ery became a bit too much.
>
>     Non changing qt5 code that I can think of is kwayland-integration
>     which is an implementation detail of kf5/plasma5
>     but we provide in plasma6 to keep kf5 apps working.
>
>
> Not a huge fan of the idea of keeping Qt 5 around in any form at all=20
> to be honest.
>
> Do the Plasma developers have a view as to when this support will be=20
> dropped given that distributions are rapidly dropping support for Qt 5?

Looking at=20
https://mail.kde.org/pipermail/distributions/2026-June/001695.html we=20
are not quite there yet when it comes to getting rid of Qt5 entirely.


> This feels like something that is going to require work to implement=20
> and will be dropped in 6 months or so given the speed distros are=20
> moving at, and if that is the case my preference would be to just move=
=20
> up the end of support and do it all now.

--------------FiNYtJgpSXSF2wJxeCjJWxnz
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-=
8">
  </head>
  <body>
    <div class=3D"moz-cite-prefix">On 29/07/2026 12:00, Ben Cooksley
      wrote:<br>
    </div>
    <blockquote type=3D"cite"
cite=3D"mid:[email protected]=
il.com">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUT=
F-8">
      <div dir=3D"ltr">
        <div dir=3D"ltr"><span style=3D"background-color:transparent">On
            Wed, Jul 29, 2026 at 7:31=E2=80=AFPM David Redondo &lt;<a
              href=3D"mailto:[email protected]" moz-do-not-send=3D"true=
"
              class=3D"moz-txt-link-freetext">[email protected]</a>&gt;
            wrote:</span></div>
        <div class=3D"gmail_quote gmail_quote_container">
          <blockquote class=3D"gmail_quote"
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">Am
            Dienstag, 28. Juli 2026, 23:36 schrieb Albert Astals Cid:<br>
            &gt; El dimarts, 28 de juliol del 2026, a les 13:20:56 (Hora
            d=E2=80=99estiu d=E2=80=99Europa <br>
            &gt; central), Nicolas Fella va escriure:<br>
            &gt; &gt; On 28/07/2026 12:52, Ben Cooksley wrote:<br>
            &gt; &gt; &gt; Hi all,<br>
            &gt; &gt; &gt; <br>
            &gt; &gt; &gt; For some time now Qt 5 has been in extended
            maintenance / support,<br>
            &gt; &gt; &gt; which Iif my understanding is correct has now
            come to an end.<br>
            &gt; &gt; &gt; <br>
            &gt; &gt; &gt; Accordingly, given that all of our
            applications have now had a<br>
            &gt; &gt; &gt; substantial amount of time to migrate, and
            plenty of notice that CI<br>
            &gt; &gt; &gt; would be withdrawn eventually, i'd like to
            proceed with withdrawing CI<br>
            &gt; &gt; &gt; support for Qt 5.<br>
            &gt; &gt; &gt; <br>
            &gt; &gt; &gt; This will free up valuable space on the CI
            nodes and allow us to<br>
            &gt; &gt; &gt; remove an image that is under very minimal,
            if any, maintenance.<br>
            &gt; &gt; &gt; <br>
            &gt; &gt; &gt; Please let me know if there are any
            objections.<br>
            &gt; &gt; <br>
            &gt; &gt; Hi,<br>
            &gt; &gt; <br>
            &gt; &gt; for applications I agree to drop Qt5 CI. The few
            usages that are left<br>
            &gt; &gt; either already have Qt6 CI, or are more or less
            dead projects.<br>
            &gt; &gt; <br>
            &gt; &gt; That said, we have a number of (Plasma) components
            that we still build<br>
            &gt; &gt; for Qt5 for (external) application compatibility
            (breeze,<br>
            &gt; &gt; plasma-integration, etc). So far we have not made
            a decision to stop<br>
            &gt; &gt; doing that, and I'd rather not lose CI for those.
            That doesn't mean we<br>
            &gt; &gt; need Qt5 CI in the current form. Could we use a
            distribution image with<br>
            &gt; &gt; Qt and the few necessary libraries/frameworks
            baked in? That would be a<br>
            &gt; &gt; much smaller image and easier to maintain than the
            current suse-qt515<br>
            &gt; &gt; image.<br>
            &gt; <br>
            &gt; Does the code of those repos change in qt5 related
            areas?<br>
            &gt; <br>
            &gt; Trying to understand what we want CI for here:<br>
            &gt;=C2=A0 * Potentially new qt5 code builds with old qt5/gcc
            distros?<br>
            &gt;=C2=A0 * Non changing qt5 code builds new gcc/stuff from
            distros?<br>
            &gt; <br>
            <br>
            breeze, oxygen and plasma-integration is<br>
            * new qt5 code builds on current distros<br>
            it changes as the qt6 code changes. The goal is that qt5 and
            qt6 applications<br>
            look and feel the same.<br>
            For breeze and oxygen the same code base is compiled twice,
            once with qt6 and once with qt5.<br>
            plasma-integration has copies of the code for qt5 and qt6
            because the ifdef'ery became a bit too much.<br>
            <br>
            Non changing qt5 code that I can think of is
            kwayland-integration which is an implementation detail of
            kf5/plasma5<br>
            but we provide in plasma6 to keep kf5 apps working.</blockquot=
e>
          <div><br>
          </div>
          <div>Not a huge fan of the idea of keeping Qt 5 around in any
            form at all to be honest.</div>
          <div><br>
          </div>
          <div>Do the Plasma developers have a view as to when this
            support will be dropped given that distributions are rapidly
            dropping support for Qt 5?</div>
        </div>
      </div>
    </blockquote>
    <p>Looking at
      <a class=3D"moz-txt-link-freetext" href=3D"https://mail.kde.org/pipe=
rmail/distributions/2026-June/001695.html">https://mail.kde.org/pipermail/=
distributions/2026-June/001695.html</a>
      we are not quite there yet when it comes to getting rid of Qt5
      entirely.</p>
    <p><br>
    </p>
    <blockquote type=3D"cite"
cite=3D"mid:[email protected]=
il.com">
      <div dir=3D"ltr">
        <div class=3D"gmail_quote gmail_quote_container">
          <div><span style=3D"background-color:transparent">This feels
              like something that is going to require work to implement
              and will be dropped in 6 months or so given the speed
              distros are moving at, and if that is the case my
              preference would be to just move up the end of support and
              do it all now.</span></div>
        </div>
      </div>
    </blockquote>
  </body>
</html>

--------------FiNYtJgpSXSF2wJxeCjJWxnz--