[QGIS-Developer] How to handle upstream Qt fixes

[Greg Troxel]

Nyall Dawson <nyall.dawson at gmail.com> writes:

> - 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/

I'm speaking as the maintainer of the qgis package in pkgsrc, a multi-OS
multi-CPU packaging system.  Currently this is 3.16.x, and it is built
against 5.15.2 (only).

I think you have posed semi-separable questions and it's good to
semi-separate them:

  - 1. should qgis target the KDE fork of QT, or 5.15.2, or both, as the
    library that is expected to be used, and tested in CI?

  - 2. when qgis.org produces binary builds, should qt-kde or qt be used?

  - 3. should qgis.org attempt to engage with KDAB to work on a fork of a
    branch discontinued by the original maintainers?

  - 4. Given what I see as concerning behavior by Qt Co in placing Free
    Software users in a bad spot, what should be the future approach to
    Qt?  Perhaps, it should be KDE Qt 5.15, and not Qt 6.)

and I think this is informed in large part by understanding the degree
to which the various packaging systems (a term that I use to include
GNU/Linux distributions) switch the KDE fork.  In my view where Debian
lands, if at all, is very influential.

I will inquire within pkgsrc about the KDE fork and intent to have our
Qt 5 packages track them.  I am guessing that it's meant to be just a
continuation of maintenance, for now, and thus quite compatible.

I think that (1) is the current primary question.  Choice (2) mostly
flows from the answer to (1), in that it's reasonable to target
5.15.2(release) but also test with 5.15.2.kde.x, and use .kde for
binaries on the theory that it has bugfixes.  It's also reasonable -- if
enough packaging systems move or provide the KDE fork -- to just say
that testing is only against that -- but qgis seems to support older Qt
anyway, and it would seem radical to demand a particular rev of 5.15 at
this point.

If (1) is decided in favor of the fork, then (3) seems reasonable.

(4) is a hard discussion that I think should be deferred a bit until we
see how the Free Software world's approach to Qt settles out.  It
reamains to be seen how that's going to go between extremes of being
content about the withdrawal of support and just moving to 6, and
deciding that qt's model wasn't such a good idea after all and that it's
best to use a truly Free fork or start to get away from it entirely.
Pretty obviously neither extreme is likely, but I have little confidence
in guesses about where we'll land.

Greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20210902/04b92eb0/attachment.sig>