Sunsetting Qt 5

[Ben Cooksley]

On Sun, Dec 1, 2024 at 10:04 AM Ingo Klöcker <kloecker at kde.org> wrote:

> On Samstag, 30. November 2024 11:51:51 Mitteleuropäische Normalzeit Albert
> Astals Cid wrote:
> > El dissabte, 30 de novembre del 2024, a les 4:57:10 (Hora estàndard del
> > Centre
> > d’Europa), Ben Cooksley va escriure:
> > > HI all,
> > >
> > > This past week or so i've been dealing with a number of issues
> relating to
> > > a handful of still Qt 5 based projects trying to make use of updated
> > > dependencies. These issues have revealed that the level of support for
> Qt
> > > 5
> > > as a platform in general is now subject to a significant degree of
> > > bit-rot.
> > > As such, we need to set a point at which we consider Qt 5 to no longer
> be
> > > supported.
> > >
> > > To start I would like to remove support for all CD builds (Windows,
> > > Appimage, macOS) as well as CI support for Windows. There is already a
> > > general view in Craft that Qt 5 is unmaintained and this removal simply
> > > reflects that.
> >
> > If the Craft maintainers don't want to maintain Qt5 and no one steps up I
> > guess that's understandable.
>
> The qt5-lts branch of Craft is no longer maintained officially since
> months.
> Those few projects who still use this branch mostly know how to deal with
> this
> and do the work themselves. As such it's IMHO unfair and untrue to say
> that Qt
> 5 is unmaintained in Craft. It's just not maintained anymore by Hannah,
> Julius
> and others who maintain the Qt 6 branches of Craft.
>
> Many of the projects which still do Qt 5 based releases on Windows are
> lighthouse projects, e.g. Kdenlive, KMyMoney, KStars. I don't think
> pulling
> the rug under their feet is fair. (I didn't forget Krita. They maintain
> their
> own CI/CD jobs as far as I know.)
>
> Isn't there a middle ground like keeping the last working Qt 5 CI images
> but
> not creating/updating them anymore? It's not as if the Qt 5 based projects
> would need to use the latest published Qt 5.15.x release or the latest
> versions of their other dependencies for patch releases. In the Craft
> builds
> they could still use newer versions of their dependencies but for CI the
> versions would be frozen.
>

Unfortunately our Windows images, due to the size of Windows itself along
with the SDKs, Visual Studio compiler, etc. are quite significant in size,
so having this split approach doesn't really work as it means the better
part of 20 GB+ of additional space is occupied on the builders.

It also means we are stuck in an essentially unmaintainable position as
nothing can be rebuilt which is a position I don't generally like to be in.
Last time that happened and was unresolvable I fired the distribution in
question from CI use and spent a chunk of time rebuilding on SUSE
Tumbleweed (which is what we have today)

Likewise, some of these projects are unfortunately pushing ahead with
wanting newer versions of Qt 5 based dependencies or are experiencing bit
rot in existing versions as other parts of the underlying system update
themselves.
We have already experienced this with:
- Microsoft pushing bad updates to MSVC 2019 (which I hacked around in
https://invent.kde.org/sysadmin/ci-images/-/commit/1f7fb1f88d39216eb6d252416d0bfd5c6cbda937
)
- Unknown updates (likely in MSys2) breaking the build of MPFR (used by
some of those lighthouse projects). As far as I can tell this is unfixable
as it is happening somewhere in some autotools code that calls on MSVC.
- Bad upstream updates leading to a broken QXMPP build (used by Kaidan)

The second one means some of those lighthouse projects can't even make use
of our CD capabilities anyway - as without MPFR they cannot be built. This
also shows that we are not properly snapshotting / keeping MSys2 stable
(which is another issue with how Craft works with MSys2)

QXMPP is a project that has caused CI maintainability issues in the past
for me and appears to be making releases without regard to their own CI
(which is failing currently).
Getting a little tired having QXMPP updates pushed through only for them
to then cause CI failures on our end - see various reverts in
https://invent.kde.org/packaging/craft-blueprints-kde/-/commits/master/qt-libs/qxmpp/qxmpp.py

Given all the above I reached the conclusion that trying to fix this is a
hopeless cause and the best solution is just to retire it as unmaintained.

Not really sure if there is a path back from how broken this all is.


>
> I do agree that new feature releases which need the newest versions of
> some
> third-party dependencies should be Qt 6 based.
>
> Regards,
> Ingo
>

Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20241201/ac795434/attachment-0001.htm>