[Qgis-developer] Drag & Drop fails on Geopackage

Giovanni Manghi giovanni.manghi at gmail.com
Wed Dec 28 07:39:29 PST 2016


Hi Matthias,


>> no, I personally found (for example) tools/features working in 2.14.3
>> that are not working in 2.14.9
>
> Which is no indication that the same did not happen in 2.8 as well but
> was unnoticed.

I think that this scenario is unlikely but certainly not impossible.




>> I may be wrong, but the during the latest bug fixing efforts the
>> regression/high priority bug list was not used as priority list.
>
> It certainly was one factor for me but in the end it's a mixed bag of
>
> - priority


In my head (and others too, I know for sure) the priority for the bug
fixing effort supported by the project is very clear: regressions
first, period. Regressions are the evil that undermine the QGIS
credibility and as such they should be squashed as soon as possible.
It is not my or your or anyone else role to judge if a regression is
important or not important. What I personally think that is not an
important regression can be a complete workflow break for "another".
And considered how many people download and use QGIS nowadays this
"other" could be very well a lot of people. In this sense I really
would like the newly elected psc to take a clear decision on this
matter, one way or the other.



> - quality of issue report
>     If there's no steps for how to reproduce it (in a reasonable time
>     and with data in reach) I'll stop right there

Fortunately the regression list is not that long, and I can say that
any ticket tagged a regression by me (or verified) has a proper
description and/or dataset to replicate. In fact when an original
description is not good enough I always edit edit it and put in front
a rephrased "new description" paragraph. This is also true for most of
the tickets tagged as "high", especially the ones know to cause crash
or data corruption.


> - expected chance of success
>     Better to spend the time fixing 3 non-critical ones than not fixing
>     a critical one
>
> - expected time to fix
>     Better to spend a day fixing 6 non-critical ones in a day than 1
>     critical ones in two days
>
> - knowledge of the codebase
>     if I know that some other dev might be better suited for something,
>     I'll probably leave it to him
>
> - knowledge of certain problems
>     if I am experiencing a problem during bugfixing, it's in front of
>     nose and I will fix it. The next time I might need 2 hours to
>     reproduce the bug. Also knowing that something is a problem for me
>     or someone I know makes it rise up my priority list.

probably from what I wrote before you understand that I respectfully
but strongly disagree with such workflow (speaking of the bug hunting
effort supported by the project).

cheers!


-- G --


More information about the Qgis-developer mailing list