[Qgis-developer] [Qgis-psc] bug tracker cleanup

Luigi Pirelli luipir at gmail.com
Mon Mar 27 03:43:04 PDT 2017


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 <giovanni.manghi at gmail.com> 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
> Qgis-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc


More information about the Qgis-developer mailing list