[QGIS-Developer] How to handle upstream Qt fixes

[Andreas Neumann]

Hi all,

Thank you Nyall for raising these questions - and Greg for joining the 
discussion.

Obviously, the questions are not easy and straight-foward to answer. 
They also depend on what the other OS projects will do about this 
situation in general.

Perhaps we can also ask the KDAB folks what they think about this 
situation and if they would recommend to continuously work on extending 
the life span of qt5x.

I can mainly comment on the financial aspects: if, after thorough 
discussion, we think that staying longer with qt5 is the way the project 
should follow, we can of course continue to invest a bit upstream to fix 
issues through KDAB. However, the risk is now higher with potential 
forks and disconnects from the official qt.

About the other questions around OSGEO4W I hope that Jürgen can give a 
useful reply - him being probably the "most technical" person on the 
QGIS PSC - and also the OSGEO4W main packager.

Thanks and greetings,

Andreas

On 2021-09-03 01:27, Greg Troxel wrote:

> 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
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20210903/2881d819/attachment.html>