<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>Hi all,</p>
<p>Thank you Nyall for raising these questions - and Greg for joining the discussion.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Thanks and greetings,</p>
<p>Andreas</p>
<p id="reply-intro">On 2021-09-03 01:27, Greg Troxel wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><br />Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> writes:<br /><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">- Qt Co effectively ended open source support of Qt 5 at the 5.15.2<br />release, and have moved all focus to Qt 6.<br />- While some preliminary work has been done, QGIS doesn't currently<br />support Qt 6 based builds, and likely won't be ready for this for some<br />time (even completely ignoring all the stable API questions a Qt 6<br />build raises entirely!)<br />- QGIS often depends on fixes and enhancements which need to be made<br />upstream in Qt, and can't be resolved or worked-around in QGIS alone<br />- KDE and other open source projects forked Qt 5.15 at<br /><a href="https://invent.kde.org/qt/qt/qtbase/-/commits/dev/" target="_blank" rel="noopener noreferrer">https://invent.kde.org/qt/qt/qtbase/-/commits/dev/</a>, and are actively<br />backporting fixes from Qt6 to that branch. Fedora recently started<br />using the KDE branch for Qt 5 library builds, so users of that<br />platform once again are getting bug fixes deployed [1]. I'm unaware if<br />other distributions or builds of Qt are using this currently.<br />- Similarly, there's a KDE fork of Qt 3d at<br /><a href="https://invent.kde.org/qt/qt/qt3d/-/commits/kde/5.15/" target="_blank" rel="noopener noreferrer">https://invent.kde.org/qt/qt/qt3d/-/commits/kde/5.15/</a></blockquote>
<br />I'm speaking as the maintainer of the qgis package in pkgsrc, a multi-OS<br />multi-CPU packaging system. Currently this is 3.16.x, and it is built<br />against 5.15.2 (only).<br /><br />I think you have posed semi-separable questions and it's good to<br />semi-separate them:<br /><br /> - 1. should qgis target the KDE fork of QT, or 5.15.2, or both, as the<br /> library that is expected to be used, and tested in CI?<br /><br /> - 2. when qgis.org produces binary builds, should qt-kde or qt be used?<br /><br /> - 3. should qgis.org attempt to engage with KDAB to work on a fork of a<br /> branch discontinued by the original maintainers?<br /><br /> - 4. Given what I see as concerning behavior by Qt Co in placing Free<br /> Software users in a bad spot, what should be the future approach to<br /> Qt? Perhaps, it should be KDE Qt 5.15, and not Qt 6.)<br /><br />and I think this is informed in large part by understanding the degree<br />to which the various packaging systems (a term that I use to include<br />GNU/Linux distributions) switch the KDE fork. In my view where Debian<br />lands, if at all, is very influential.<br /><br />I will inquire within pkgsrc about the KDE fork and intent to have our<br />Qt 5 packages track them. I am guessing that it's meant to be just a<br />continuation of maintenance, for now, and thus quite compatible.<br /><br />I think that (1) is the current primary question. Choice (2) mostly<br />flows from the answer to (1), in that it's reasonable to target<br />5.15.2(release) but also test with 5.15.2.kde.x, and use .kde for<br />binaries on the theory that it has bugfixes. It's also reasonable -- if<br />enough packaging systems move or provide the KDE fork -- to just say<br />that testing is only against that -- but qgis seems to support older Qt<br />anyway, and it would seem radical to demand a particular rev of 5.15 at<br />this point.<br /><br />If (1) is decided in favor of the fork, then (3) seems reasonable.<br /><br />(4) is a hard discussion that I think should be deferred a bit until we<br />see how the Free Software world's approach to Qt settles out. It<br />reamains to be seen how that's going to go between extremes of being<br />content about the withdrawal of support and just moving to 6, and<br />deciding that qt's model wasn't such a good idea after all and that it's<br />best to use a truly Free fork or start to get away from it entirely.<br />Pretty obviously neither extreme is likely, but I have little confidence<br />in guesses about where we'll land.<br /><br />Greg</div>
<br />
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">_______________________________________________<br />QGIS-Developer mailing list<br /><a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br />List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br />Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></div>
</blockquote>
<p><br /></p>
</body></html>