[Qgis-developer] Drag & Drop fails on Geopackage

[Tim Sutton]

Hi

> On 28 Dec 2016, at 5:39 PM, Giovanni Manghi <giovanni.manghi at gmail.com> wrote:
> 
> 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).

In an ideal world, the person who introduced the regression should be the one that fixes it but we don't have the leverage to enforce that.
Also in an ideal world, regressions will take first place in the bug hunting priority list. I think it is also fair to appreciate that our resources are limited and our control over who steps forward to do bug hunting is limited. So if we get three devs in a given release bug fix sprint that have time available to fix bugs, and none of them have familiarity with the code related to the regression, it can be a difficult sell to insist that they only focus on the regressions - they might simply make themselves unavailable for the bug fixing sprint. So until we reach the point one day where we have developers on QGIS.org's permanent payroll who we can directly mandate what work they do, we are always going to have to approach any conversation about mandatory behavior with the knowledge that our influence is limited when it comes down to exactly what we can and can't insist developers do. Our current options in terms of incentives are:

* financial: offer cash for fixes and hope that entices someone to work on the regression
* charm: appeal to a developer who is likely skilled enough to deal with it in a friendly way and see if we can get them involved in the fix
* coercion: revoke commit rights for devs who introduce regressions and don't fix them or other similar approaches
* open communication: include in the changelog and release announcements a list of known issues and regressions

We already employ the first two in the list and I would like to use the last approach too and avoid the third as much as possible. Giovanni I do understand and agree with all the points you laid out and I'd be more than happy if we emphasize more when we contract devs on QGIS funding to fix issues that they should focus on regressions first. But I don't know if we will ever get to the black and white situation where we can mandate that all regressions should be fixed before any other work can be carried out. I'll table it in the next PSC meeting and see if others can suggest a better way to approach this...

Regards

Tim




---

Tim Sutton
QGIS Project Steering Committee Chair
tim at qgis.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20161228/aab7374a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qgis_icon.jpg
Type: image/jpeg
Size: 4642 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20161228/aab7374a/attachment.jpg>