Hi Giovanni just a little correction that you can find in the same issue #15803
I'm working on that and I found that the error affects also master (qgis3) if I'm not wrong the fix isn't complex and I'm preparing PR... this fix has the same nature of the https://hub.qgis.org/issues/15976, the reason that sortColumn() normally was set to it's initial value -1 in: QSortFilterProxyModel but, somewere in qgis code (probaly in the init of QgsMapLayerProxyModel) already set a sortColumn => the normal flow skip default call to sort(0) during first open. I'll investigate 15976 too Luigi Pirelli ************************************************************************************************** * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com * LinkedIn: https://www.linkedin.com/in/luigipirelli * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli * GitHub: https://github.com/luipir * Mastering QGIS 2nd Edition: * https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition ************************************************************************************************** On 27 March 2017 at 12:02, Giovanni Manghi <[email protected]> wrote: > Hi All, > > > this thread didn't get the traction I was hooping for, is this a > indication that is a general opinion that all the fixing effort should > be focused on qgis3 and not also on the next LTR? > > >>> Speaking about the severe list you may have noticed that there are >>> issues that are known since a long ago, but there are also others that >>> are *pretty recent*, in fact there are a few regressions that have >>> slip into 2.18 since 2.14. Releasing now 2.18 as new LTR would mean >>> effectively releasing a worse QGIS compared to 2.14. >> >> thanks for spotting this. >> >>> I would like to understand if before the release of the next LTR there >>> will be scheduled bug fixing effort, as has been done for other >>> releases; and, if in this is the case, it will be a targeted one, in >>> order to give the priority to regressions that have appeared between >>> 2.14 and 2.18. >> >> it makes sense to me. how many do you think are important to fix? >> how many affect 2.18 only, not 3? > > > during my cleanup a couple of weeks ago I clearly separated the > regressions affecting only master/qgis3 and the ones only affecting > 2.18.*. In the second case I tried to my best to also try clearly > separate the ones we know since more or less long time and the ones > that have appeared after 2.14. > > The following list is a sample of important things (to me) that have > regressed in 2.18 since 2.14: > > 16242 QGIS 2.18.4 saves always with absolute paths > 15961 Escaping out of Dialog causes QGIS to crash > 15803 2.18: Move Selection to Top not working in attribute table > 15976 Attribute table: rows are switching when adding attributes > 16302 Quick calculation bar causes QGIS crash when updating fields with > aliases > 16186 Broken Processing/GRASS tools under Windows > this is a > packaging issue and not a Processing one > 15868 Frequent errors in DB Manager: `pyqtSignal must be bound to a > QObject, not 'PGVectorTable'` > 16295 DB Manager: error importing data into GPKG connections > 16296 Cannot use anymore d&d to import a layer from Spatialite in PostGIS > 16297 (macOS) layers imported into a Spatialite Database with DB > manager are not recognized as spatial tables > 15741 PostGIS issue when using 'Merge selected features' tool > (Geometry type does not match column type) > this is very bad as > causes data loss > 15974 Rows of the attribute table seem to be duplicated when saving > edits in a shapefile > > > > > > > > > > > > >>> Note: we should really do something to ask people to be more >>> disciplined when posting issues, making for example the category >>> mandatory and somehow help choosing the correct priority > ex: if is >>> a regression then “severe”, if causes a crash then “high”, use normal >>> for all the other cases. We should also state/force the users to try >>> in a clean environment, with no 3rd party plugins before reporting. >> >> Agreed fully. IMHO https://www.debian.org/Bugs/Developer#severities are >> a good reference. >> >>> Note2: I would really like to do a major cleanup of the tracker in Essen. >> >> Great, please tell if you need help, I'm available. > > > > The developer meeting is in 1 month time. I would like to discuss > *now* a few cleanups so we don't have to do it in Essen and there I > can use my time to put them in action. > > I assume that we are sticking with Redmine, correct? Here a list of > suggestions open for disccusion: > > * the platform version is very old (2010), can we try upgrade it? If > someome provides me with a copy of the db I would give it a go on a > testbench > * remove all the projects others than "QGIS Application" from > http://hub.qgis.org/projects > * close all tickets that were last updated/commented more than... 2/3/4 years? > > > cheers! > > -- G -- > _______________________________________________ > Qgis-psc mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/qgis-psc _______________________________________________ Qgis-developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
