[QGIS-Developer] Some thought on LTR

[Nyall Dawson]

On Wed, 31 Jul 2019 at 23:16, matteo <matteo.ghetta at gmail.com> wrote:
>
> Hi devs,
>
> I just discovered a serious bug in LTR on a Ubuntu 16.04 machine (on
> 16.04 QGIS 3.4 is the most updated version an user can have). Same issue
> as listed here [0].

Is your link to [0] incorrect? It's the same as [1], which was
resolved very quickly after identification...

> some big regressions ([1], [2]...)

...and honestly, I don't think [1] was a huge regression. It resulted
from a fix for GRASS handling on Windows with non-ascii paths, and
only affected Ubuntu 16.04 users. The number of users affected by the
original issue would be much, MUCH greater than the number of Ubuntu
16.04 users of GRASS algorithms. And a fix was pushed almost
immediately after the bug was reported, so to me this one is just bad
luck, and not symptomatic of problems in our development processes.
(The only "fix" I could see as possible here would be to add Ubuntu
16.04 as a platform on which our CI tests are run, but to do that we'd
need to pay and upgrade from the free Travis account we currently use
and get access to unlimited parallel builds. We're already struggling
with the limitations in parallel builds on the free account with just
one build target).

> [2]

I don't see any evidence that [2] is a regression and not a feature
request, as I'm of the impression this has never been supported by the
inbuilt browser. In fact, it's only recently that QGIS browser backend
would be able to support this kind of mixed-provider structure (i.e.
postgis provider node which shows layers which must be loaded via
gdal), (and I'm only 50-50 that it would be possible currently without
further API work).

Sounds like a good goal though, and would be a great followup to
Alessandro's upcoming dbmanager -> browser work. I'm personally of the
impression that Postgis raster's have never been a first class citizen
in QGIS, and have only ever worked
kind-of-sort-of-if-you-hold-your-breathe-right. It would be great to
see this remedied and them become fully supported via browser and the
data source manager, and covered by unit tests so that we CAN safely
rely on accessing them in QGIS.

> I'm not writing this email because I have a proposal, I'm just curious
> if someone else feels the same: of course it is normal to have bug (and
> regressions) but I really think we should think to enhance a little bit
> more the LTR...

I'm not saying that we DON'T have some bad regressions which slip in
occasionally to the LTR (the recent db manager regression discussion
comes to mind), but I honestly don't think there's a bigger problem
here. Everything listed here (GRASS provider, PostGIS rasters, db
manager edge cases) have always had a shaky past in QGIS, and
regressions to them are (and ALWAYS have been) common. So I don't
think the issue lies in the LTR or the handling of it, rather the
issue lies in the code and lack of stability in these parts of QGIS.
(Mathieu - might be time for your thread on one of these points...
hint hint!)

Nyall



>
> Cheers and thanks for feedback
>
> Matteo
>
>
> [0]
> http://osgeo-org.1560.x6.nabble.com/Problem-with-PROCESSING-GRASS-Algorithms-td5392185.html
> [1]
> http://osgeo-org.1560.x6.nabble.com/Problem-with-PROCESSING-GRASS-Algorithms-td5392185.html
> [2] https://github.com/qgis/QGIS/issues/30211
> _______________________________________________
> 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