Re: Decommissioning Qt 5 CI

--0000000000001ffe140657d88556
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 31, 2026 at 12:02=E2=80=AFAM Kisaragi Hiu <[email protected]=
m> wrote:

> 2026/07/30 19:23 Ben Cooksley <[email protected]>:
>
> Seems that some distributions are actually going ahead with full removal
> or have already done so which matches up with the view that it is well an=
d
> truly dead?
>
>
> I do not get the feeling that it's "well and truly dead" at all from the
> thread; at least not yet. It seems very much still in the "people are
> working hard to put it to rest" stage.
>
> - Arch, Slackware, and FreeBSD all mention waiting on KDE to at least mak=
e
> releases for KDE apps that have already been ported but just haven't made=
 a
> release after porting (kaffeine, kbibtex, krename, kronometer, kdesvn) or
> for more KDE apps to be ported (Okteta).
>

From the perspective of CI, apps not being released is not a problem - as
CI is supporting future state not prior state.


> - Arch still ships VLC with Qt5 (but this is. probably not a problem? VLC
> already supports Qt6 now, right? If anything it shouldn't be hard to get
> VLC to fix its Qt6 support)
> - "Adelie Linux" notes "the most important Qt 5 software is Quassel IRC"
> and why it's used. The last commit is in June, the second last commit is
> from July 2025, so it's not quite active but not dead either. Though a
> porting effort does exist.
>

For all intents and purposes that sounds like Quassel is dead.


> - Gentoo has done full removal. For Okteta, they use the work/kossebau/kf=
6
> branch.
>   https://mail.kde.org/pipermail/distributions/2026-June/001705.html
>   https://packages.gentoo.org/packages/app-editors/okteta
>
> https://gitweb.gentoo.org/repo/gentoo.git/tree/app-editors/okteta/okteta-=
0.26.60_pre20260628.ebuild
> - Ubuntu is moving towards removal but hasn't done so yet even in the
> 26.10 branch.
>   https://packages.ubuntu.com/stonking/okteta
>
>
> This feels like quite a bit of effort being justified for a few small
> pieces of software that will only be used by a small number of applicatio=
ns
> (as most have ported) that are themselves legacy and likely to have
> maintenance issues (because otherwise they'd be ported already).
>
> In my view, the expense of maintaining Qt 5 support for that very small
> handful of Plasma projects is not particularly well justified.
>
>
> While I understand why we want to move on from Qt5, if we do it now it
> should be done with the understanding that it's not zero impact. It's
> probably still worth it, but then the last unported-but-still-wanted or
> ported-but-unreleased KDE apps should still be resolved first.
>
> Specifically: kaffeine, kbibtex, krename, kronometer, kdesvn, and maybe
> systemdgenie[1] are ported but unreleased and need a release; Okteta is n=
ot
> ported yet but probably still wanted (ie. can't just deprecate Okteta). I=
f
> the desire to decommission now is high, that should be turned into a desi=
re
> to release what's been ported and port + release Okteta first.
>

The removal of Qt 5 CI was well telegraphed with an initial sunset planned
for September last year that was pushed back because people "needed more
time".
I don't see any reason why we should keep extending this - there are no
longer releases of Frameworks being made to support Qt 5, and Qt 5 itself
is out of even extended security support upstream.


>
> [1]: I got this list from looking at which packages depend on kcoreaddons=
5
> in Arch
> https://archlinux.org/packages/extra/x86_64/kcoreaddons5/
>
> Best regards,
> Kisaragi Hiu
>

Thanks,
Ben

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

<div dir=3D"ltr"><div dir=3D"ltr"><span style=3D"background-color:transpare=
nt">On Fri, Jul 31, 2026 at 12:02=E2=80=AFAM Kisaragi Hiu &lt;<a href=3D"ma=
ilto:[email protected]">[email protected]</a>&gt; wrote:</span></di=
v><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">2026/07/30 19=
:23 Ben Cooksley &lt;<a href=3D"mailto:[email protected]" target=3D"_blank"=
>[email protected]</a>&gt;:</div><div><div><blockquote style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
 dir=3D"ltr"><div><div>Seems that some distributions are actually going ahe=
ad with full removal or have already done so which matches up with the view=
 that it is well and truly dead?</div></div></div></blockquote></div></div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">I do not get the feeling that=
 it&#39;s &quot;well and truly dead&quot; at all from the thread; at least =
not yet. It seems very much still in the &quot;people are working hard to p=
ut it to rest&quot; stage.</div><div dir=3D"auto"></div><div dir=3D"auto"><=
br></div><div dir=3D"auto">- Arch, Slackware, and FreeBSD all mention waiti=
ng on KDE to at least make releases for KDE apps that have already been por=
ted but just haven&#39;t made a release after porting (kaffeine, kbibtex, k=
rename, kronometer, kdesvn) or for more KDE apps to be ported (Okteta).</di=
v></div></blockquote><div><br></div><div>From the perspective of CI, apps n=
ot being released is not a problem - as CI is supporting future state not p=
rior state.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"auto"><div dir=3D"auto">- Arch still ships VLC with =
Qt5 (but this is. probably not a problem? VLC already supports Qt6 now, rig=
ht? If anything it shouldn&#39;t be hard to get VLC to fix its Qt6 support)=
</div><div dir=3D"auto">- &quot;Adelie Linux&quot; notes &quot;the most imp=
ortant Qt 5 software is Quassel IRC&quot; and why it&#39;s used. The last c=
ommit is in June, the second last commit is from July 2025, so it&#39;s not=
 quite active but not dead either. Though a porting effort does exist.</div=
></div></blockquote><div><br></div><div>For all intents and purposes that s=
ounds like Quassel is dead.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">- Gentoo has d=
one full removal. For Okteta, they use the work/kossebau/kf6 branch.</div><=
div dir=3D"auto">=C2=A0 <a href=3D"https://mail.kde.org/pipermail/distribut=
ions/2026-June/001705.html" target=3D"_blank">https://mail.kde.org/pipermai=
l/distributions/2026-June/001705.html</a></div><div dir=3D"auto">=C2=A0 <a =
href=3D"https://packages.gentoo.org/packages/app-editors/okteta" target=3D"=
_blank">https://packages.gentoo.org/packages/app-editors/okteta</a></div><d=
iv dir=3D"auto">=C2=A0 <a href=3D"https://gitweb.gentoo.org/repo/gentoo.git=
/tree/app-editors/okteta/okteta-0.26.60_pre20260628.ebuild" target=3D"_blan=
k">https://gitweb.gentoo.org/repo/gentoo.git/tree/app-editors/okteta/okteta=
-0.26.60_pre20260628.ebuild</a></div><div dir=3D"auto">- Ubuntu is moving t=
owards removal but hasn&#39;t done so yet even in the 26.10 branch.</div><d=
iv dir=3D"auto">=C2=A0 <a href=3D"https://packages.ubuntu.com/stonking/okte=
ta" target=3D"_blank">https://packages.ubuntu.com/stonking/okteta</a></div>=
<div dir=3D"auto"><br></div><div dir=3D"auto"><div><blockquote style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div dir=3D"auto"><br></div><div dir=3D"auto">This fee=
ls like quite a bit of effort being justified for a few small pieces of sof=
tware that will only be used by a small number of applications (as most hav=
e ported) that are themselves legacy and likely to have maintenance issues =
(because otherwise they&#39;d be ported already).</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">In my view, the expense of maintaining Qt 5 suppo=
rt for that very small handful of Plasma projects is not particularly well =
justified.</div></div></blockquote></div></div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">While I understand why we want to move on from Qt5, if we=
 do it now it should be done with the understanding that it&#39;s not zero =
impact. It&#39;s probably still worth it, but then the last unported-but-st=
ill-wanted or ported-but-unreleased KDE apps should still be resolved first=
.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Specifically: kaffeine=
, kbibtex, krename, kronometer, kdesvn, and maybe systemdgenie[1] are porte=
d but unreleased and need a release; Okteta is not ported yet but probably =
still wanted (ie. can&#39;t just deprecate Okteta). If the desire to decomm=
ission now is high, that should be turned into a desire to release what&#39=
;s been ported and port + release Okteta first.</div></div></blockquote><di=
v><br></div><div>The removal of Qt 5 CI was well telegraphed with an initia=
l sunset planned for September last year that was pushed back because peopl=
e &quot;needed more time&quot;.</div><div>I don&#39;t see any reason why we=
 should keep extending this - there are no longer releases of Frameworks be=
ing made to support Qt 5, and Qt 5 itself is out of even extended security =
support upstream.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"au=
to">[1]: I got this list from looking at which packages depend on kcoreaddo=
ns5 in Arch</div><div dir=3D"auto"><a href=3D"https://archlinux.org/package=
s/extra/x86_64/kcoreaddons5/" target=3D"_blank">https://archlinux.org/packa=
ges/extra/x86_64/kcoreaddons5/</a></div><div dir=3D"auto"><br></div><div di=
r=3D"auto">Best regards,</div><div dir=3D"auto">Kisaragi Hiu</div></div></b=
lockquote><div><br></div><div>Thanks,</div><div>Ben=C2=A0</div></div></div>

--0000000000001ffe140657d88556--