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.daw...@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
