[Qgis-psc] [QGIS-Developer] How to handle upstream Qt fixes

[Nyall Dawson]

On Thu, 9 Sept 2021 at 10:33, Greg Troxel <gdt at lexort.com> wrote:
>
>
> Nyall Dawson <nyall.dawson at gmail.com> writes:
>
> > I'd never make the KDE fork a requirement for a bulid -- we'd always
> > have to ensure that users can build using the official releases.
> > They'd just potentially suffer from upstream Qt bugs which have since
> > been fixed in the community fork. (And if we do nothing, they'd be in
> > exactly the same situation!!)
>
> I guess then I'm not sure what the question is.  It seems clear:
>
>   qgis source code should build against qt 5.15.2 and also against qtx
>   5.15.next (or whatever it's called), and perhaps against some earlier
>   qt 5.x
>
>   if something goes wrong that's a qt bug, then probably some reasonable
>   effort might be made to accomodate it, but if it's fixed in qtx and
>   not in qt-frozen, then perhaps not so much
>
>   maybe qgis would declare that the fork is the preferred source of qt5.
>
>   people who build binaries will choose what they choose.  Maybe there
>   would be some sort of "the standard approach is [version-x] for qt"
>   guidance statement, and maybe there wouldn't be.
>
>   project-built binaries need to choose
>
> So I'm still not entirely clear what question is on the table

Whether QGIS will get its money worth from contracting KDAB to fix Qt
issues in the 5.15.next fork, or whether we "give up" on Qt upstream
fixes until we can move wholesale to Qt 6.

>
> >> Maybe it's time for another 'big gap' in QGIS releases? As in: after
> >> 3.22 (LTR) there will be a probably not so stable 4.0 which will
> >> have a thorough api cleanup (first), while maybe partially trying to
> >> do some pre-work for Qt6? And so hopefully we will have Qt6 packaged
> >> more easily at that time?
> >
> > See https://github.com/qgis/QGIS-Enhancement-Proposals/issues/198 for
> > my proposal on how we handle this. I'd suggest that (when we're ready)
> > we do a "soft break" and support Qt 6 builds of QGIS 3.x, with the
> > intention of moving the Windows and Mac builds to Qt 6. We don't allow
> > ANY api breaks which aren't directly related to making QGIS qt6
> > compatible, so that plugins will only have to make very minimal
> > changes (if any)
>
> comments on QEP198
>
>   I do not follow how qt 5.15.2 won't work on Apple aarch64.  Presumably
>   it can be built on Linux/BSD aarch64, and the apple interfaces at the
>   source level remain.  Maybe that's out of date, maybe I'm confused.
>   Maybe it is fixed in the fork.

Upstream has stated multiple times that M1 isn't supported on Qt 5.15,
and that there's known issues which won't be fixed. The new
architecture requires Qt 6 for proper support. I can't comment on the
severity of those known issues, but suffice to say if Qt 5 works on M1
then it's more of a happy accident then anything stable...!

>
>   I don't really see how cleaning up deprecation warnings in 5.15, while
>   keeping the codebase entirely ok when built with 5.15, is a break,
>   other than from older qt5.  If that's what you mean, that's fine  -
>   but if you mean something else, I did not follow.

I'm referring to QGIS specific deprecated methods, not Qt ones.
There's lots of deprecated methods throughout the QGIS api which have
been left in place for plugins only, and I'm proposing that we
**don't** touch these.

>
>   It's almost a year later, so I wonder how the build w/o deprecation
>   warnings is going.  I think you said there's about 4 FTE-weeks more
>   work.

We can build without any deprecation warnings, there's no issue there.
But Qt upstream was lying (misguided?) when they claimed that code
which builds without warning on Qt 5.15 would "just work" on Qt 6.

Nyall

>
>   It would be really nice if the next LTR was dual 5.15/6.  (Sorry, I
>   have no spare ponys for you.)
>
> >> What is the Qt6 status in Fedora or Suse?
> >
> > Fedora has qt 6.1 packages from Fedora 34 (we use these on the CI to
> > test builds of the core/analysis library on Qt 6). Not sure about SUSE
> > personally.
>
> pkgsrc has qt5 5.15.2 currently, and has qt6 packages in our separate
> draft repository.  I am not hearing a lot about imminently moving them
> to pkgsrc proper.  Overall I get the sense that qt6 has not fully
> arrived.  I realize it's been a while formal release of 6.0, but it
> seems like enough of a departure that it's difficult.