[QGIS-Developer] How to handle upstream Qt fixes

[Nyall Dawson]

On Sat, 4 Sept 2021 at 07:03, Jürgen E. Fischer <jef at norbit.de> wrote:
>
> Hi Nyall,
>
> On Fri, 03. Sep 2021 at 08:46:21 +1000, Nyall Dawson wrote:
> > - 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 asked on #debian-qt-kde on OFTC and they are apparently not planning to apply
> the patch collection blindly, but probably would apply individual patches (of
> the currently 222 qtbase and 33 in qt3d patches) that we need.

Ok, thanks for the insights. FWIW it looks like Fedora is taking the
opposite direction and will be migrating ALL Qt packages to the
community forks. See
https://bugzilla.redhat.com/show_bug.cgi?id=2000789#c1

>
> > 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].
>
> Do you know whether the PDF issue is already addressed in the patch collection?

No, it's still open upstream:
https://bugreports.qt.io/browse/QTBUG-86094 . (So even if we moved to
qt6 today it'd still be an issue).

> > - 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?
>
> I suppose so - I would probably just apply them all in OSGeo4W and hope for the
> best ;)

I honestly don't think there'd be any higher risk in trusting the
community fork vs the official Qt releases. We all know how often
those regress *eye roll*. Maybe a community maintained fork is EXACTLY
what Qt needs to get back on track.

> > - If we can get the majority of our users onto builds which use the
> >   KDE backports branch (i.e. Windows/mac users)
>
> Do we know that there are significantly more users on Mac than on free
> platforms?

Nope. I'm mostly referring to Windows there!

Nyall

> >  , 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).
>
> I'd say yes.
>
>
> Jürgen
>
> --
> Jürgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
> Dipl.-Inf. (FH)             Rheinstraße 13          Fax. +49-4931-918175-50
> Software Engineer           D-26506 Norden            https://www.norbit.de
> QGIS release manager (PSC)  Germany                 IRC: jef on Libera|OFTC