On Wed, 31 Jul 2019 at 23:16, matteo <matteo.ghe...@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@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