[QGIS-Developer] How to handle upstream Qt fixes

[Nyall Dawson]

Hi PSC, devs,

I'd like to kick start some discussion on how best to handle the
situation with upstream Qt and their (lack of) support for Qt 5. As a
quick summary of the situation:

- Qt Co effectively ended open source support of Qt 5 at the 5.15.2
release, and have moved all focus to Qt 6.
- While some preliminary work has been done, QGIS doesn't currently
support Qt 6 based builds, and likely won't be ready for this for some
time (even completely ignoring all the stable API questions a Qt 6
build raises entirely!)
- QGIS often depends on fixes and enhancements which need to be made
upstream in Qt, and can't be resolved or worked-around in QGIS alone
- KDE and other open source projects forked Qt 5.15 at
https://invent.kde.org/qt/qt/qtbase/-/commits/dev/, and are actively
backporting fixes from Qt6 to that branch. Fedora recently started
using the KDE branch for Qt 5 library builds, so users of that
platform once again are getting bug fixes deployed [1]. I'm unaware if
other distributions or builds of Qt are using this currently.
- Similarly, there's a KDE fork of Qt 3d at
https://invent.kde.org/qt/qt/qt3d/-/commits/kde/5.15/

Right now, there's a number of very frustrating issues that Qt 5.15.2
has which impact our users. An example is #44876, which results in
very large PDF exports from QGIS with broken hairline line rendering
[2]. In the past QGIS has contracted KDAB as part of the QGIS bug
fixing efforts to directly fix issues which affect QGIS users
upstream, with good results. Unfortunately, given that we are stuck on
Qt 5.15.2 and upstream won't release any more 5.15.x versions, we
can't just do that same approach again to get fixes into Qt.

So I'd like to raise discussions about the best way we can handle this
situation as a downstream project.

My thoughts/questions:

- Are we free to change the Windows builds to use the KDE backports
fork of 5.15 instead of the official 5.15.2 releases? (Or does that
change lots of osgeo4w packaging things?). Similarly, are we free to
move the MacOS builds to the KDE branch too?
- Could we also move the Windows/MacOS builds of Qt 3d to use the KDE fork?
- Does anyone know if Debian have plans to migrate to the KDE
backports fork? (Last I heard, the debian Qt maintainers stepped down
and the package is currently lacking a maintainer!)
- If we can get the majority of our users onto builds which use the
KDE backports branch (i.e. Windows/mac users), could we re-start the
relationship with KDAB and contract them for bug fixes again for 3.22?
(with the arrangement explicitly requiring them to backport fixes to
Qt 5 via KDE's fork).

Nyall

[1] https://src.fedoraproject.org/rpms/qt5-qtbase/c/400d49b3925dc2852218289310674abd3950b4e0?branch=rawhide
[2] https://github.com/qgis/QGIS/issues/44876