Re: [QGIS-Developer] Running grass algorithms in threads

[Vaclav Petras]

On Tue, Aug 14, 2018 at 8:52 PM, Vaclav Petras  wrote:

>
> # and delete the rest
> rm ~/grassdata/nc_spm/par1
> rm ~/grassdata/nc_spm/par2
> rm ~/grassdata/nc_spm/par3
> rm ~/grassdata/nc_spm/par4
>


Of course `rm -r` here.
___
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

Re: [QGIS-Developer] Running grass algorithms in threads

[Vaclav Petras]

On Tue, Aug 14, 2018 at 7:10 PM, Nyall Dawson 
wrote:

> On Tue, 14 Aug 2018 at 21:43, Rudi von Staden  wrote:
> >
> > Hi all,
> >
> > The bottleneck in my script at the moment is the calculation of zonal
> stats using 'grass7:r.stats.zonal'. I thought I might speed things up by
> using QgsTask.fromFunction() or QgsProcessingAlgRunnerTask() to run these
> calculations in parallel. In my tests of both approaches the tasks seem to
> complete (task.status() == QgsTask.Complete), but the output file is only
> generated for 1 of 4 parallel tasks (the task that finishes first).
> >
> > I'm assuming this is because grass algorithms are not thread safe? Or am
> I missing something in my implementation that could make this work?
>
> I strongly suspect that grass algorithms cannot be run in parallel.
> This is why they cannot run in the background in QGIS like the
> native/GDAL algorithms can. But I'd love for confirmation about this
> and whether there's any way to make GRASS multi-thread safe.
>


In general, it works. You can run GRASS modules in parallel if you set
things right which is best achieved by running the parallel processes in
separate GRASS mapsets.

GRASS modules are separate processes, so we are talking about parallel
processes, rather than threads, so there are pretty separated. You can run
for example (assuming GRASS GIS session in NC SPM location, new/empty
mapset, and Linux command line, so that & starts process in the background):

r.neighbors input=elevation output=elevation_1 size=21 &
r.neighbors input=elevation output=elevation_2 size=21 &
r.neighbors input=elevation output=elevation_3 size=21 &
r.neighbors input=elevation output=elevation_4 size=21 &

However, conflicts may arise if you are changing computational region at
the same time as doing calculations or if you are writing vectors using the
default settings for attribute table, i.e. one SQLite db for all vector
maps in a mapset. You can make these things work, e.g. by passing a
computational region through environment rather than by g.region or by
using different backend for attributes. However, the safest way are the
separate mapsets, for example (assuming Linux for & and an existing
location called nc_spm):

# create the mapsets
grass -e -c ~/grassdata/nc_spm/par1
grass -e -c ~/grassdata/nc_spm/par2
grass -e -c ~/grassdata/nc_spm/par3
grass -e -c ~/grassdata/nc_spm/par4
# run v.random (just an example which creates vector with attributes)
grass ~/grassdata/nc_spm/par1 --exec v.random output=points_1 column=value
npoints=100 &
grass ~/grassdata/nc_spm/par2 --exec v.random output=points_2 column=value
npoints=100 &
grass ~/grassdata/nc_spm/par3 --exec v.random output=points_3 column=value
npoints=100 &
grass ~/grassdata/nc_spm/par4 --exec v.random output=points_4 column=value
npoints=100 &
# just to finish the example, let's merge the vectors in a new mapset
grass -e -c ~/grassdata/nc_spm/par
grass ~/grassdata/nc_spm/par --exec v.patch input=points_1@par1
,points_2@par2,points_3@par3,points_4@par4 output=points
grass ~/grassdata/nc_spm/par --exec v.info map=points -t
# and delete the rest
rm ~/grassdata/nc_spm/par1
rm ~/grassdata/nc_spm/par2
rm ~/grassdata/nc_spm/par3
rm ~/grassdata/nc_spm/par4

I'm assuming that we are talking about running algorithms in parallel in
QGIS, not parallelism inside the algorithms. Other considerations apply to
that (parallelization is controlled by the modules themselves, see e.g.
nprocs option for r.sun or v.surf.rst in G 7.4). Note that I'm talking
about (pure) GRASS, so it depends how QGIS is handling it (I recall it is
using --exec, but I don't know what it is doing with locations and
mapsets). Please also note that I didn't measure if the v.random example
would be actually more advantageous the a single process.

Best,
Vaclav


> Because this is grass related (and not QGIS specific) I'd suggest
> asking on the grass mailing list, and relaying any responses back
> here.
>

> Nyall
>
> >
> > Thanks,
> > Rudi
> >
> >
> >
> > My code for the QgsTask approach is as below:
> >
> > def getZonal(task, habitatModelFile, cover):
> > tempFile = QgsProcessingUtils.generateTempFilename("output.tif")
> > processing.run("grass7:r.stats.zonal", {
> > 'base':habitatModelFile,
> > 'cover':cover,
> > 'method':5,
> > '-c':False,
> > '-r':False,
> > 'output':tempFile,
> > 'GRASS_REGION_PARAMETER':None,
> > 'GRASS_REGION_CELLSIZE_PARAMETER':0,
> > 'GRASS_RASTER_FORMAT_OPT':'',
> > 'GRASS_RASTER_FORMAT_META':''},context=context,feedback=
> algFeedback)
> >
> > if task.isCanceled():
> > deleteFile(tempFile)
> > return
> >
> > return tempFile
> >
> > ls90Task = QgsTask.fromFunction('LS90', getZonal, habitatModelFile=hm1,
> cover=ls90Layer)
> > QgsApplication.taskManager().addTask(ls90Task)
> > feedback.pushInfo("Calculating LS14 mean...")
> > ls14Task = QgsTask.fromFunction('LS14 ', getZonal, 

Re: [QGIS-Developer] ShapeTools News and Updates

[Nyall Dawson]

On Wed, 15 Aug 2018 at 02:19, C Hamilton  wrote:
> ...and some of the shapes have been ported to the processing framework. 
> Eventually all will be in processing

Great to hear! Some of this functionality is fundamental stuff which
would be lovely to include in a default QGIS install, and porting to
processing would be a natural first step toward this. Keep us posted
as you progress!

Nyall

.
>
> Calvin
> ___
> 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

Re: [QGIS-Developer] Running grass algorithms in threads

[Nyall Dawson]

On Tue, 14 Aug 2018 at 21:43, Rudi von Staden  wrote:
>
> Hi all,
>
> The bottleneck in my script at the moment is the calculation of zonal stats 
> using 'grass7:r.stats.zonal'. I thought I might speed things up by using 
> QgsTask.fromFunction() or QgsProcessingAlgRunnerTask() to run these 
> calculations in parallel. In my tests of both approaches the tasks seem to 
> complete (task.status() == QgsTask.Complete), but the output file is only 
> generated for 1 of 4 parallel tasks (the task that finishes first).
>
> I'm assuming this is because grass algorithms are not thread safe? Or am I 
> missing something in my implementation that could make this work?

I strongly suspect that grass algorithms cannot be run in parallel.
This is why they cannot run in the background in QGIS like the
native/GDAL algorithms can. But I'd love for confirmation about this
and whether there's any way to make GRASS multi-thread safe.

Because this is grass related (and not QGIS specific) I'd suggest
asking on the grass mailing list, and relaying any responses back
here.

Nyall

>
> Thanks,
> Rudi
>
>
>
> My code for the QgsTask approach is as below:
>
> def getZonal(task, habitatModelFile, cover):
> tempFile = QgsProcessingUtils.generateTempFilename("output.tif")
> processing.run("grass7:r.stats.zonal", {
> 'base':habitatModelFile,
> 'cover':cover,
> 'method':5,
> '-c':False,
> '-r':False,
> 'output':tempFile,
> 'GRASS_REGION_PARAMETER':None,
> 'GRASS_REGION_CELLSIZE_PARAMETER':0,
> 'GRASS_RASTER_FORMAT_OPT':'',
> 'GRASS_RASTER_FORMAT_META':''},context=context,feedback=algFeedback)
>
> if task.isCanceled():
> deleteFile(tempFile)
> return
>
> return tempFile
>
> ls90Task = QgsTask.fromFunction('LS90', getZonal, habitatModelFile=hm1, 
> cover=ls90Layer)
> QgsApplication.taskManager().addTask(ls90Task)
> feedback.pushInfo("Calculating LS14 mean...")
> ls14Task = QgsTask.fromFunction('LS14 ', getZonal, habitatModelFile=hm2, 
> cover=ls14Layer)
> QgsApplication.taskManager().addTask(ls14Task)
> hs90Task = QgsTask.fromFunction('HS90 ', getZonal, habitatModelFile=hm3, 
> cover=hs90Layer)
> QgsApplication.taskManager().addTask(hs90Task)
> hs14Task = QgsTask.fromFunction('HS14 ', getZonal, habitatModelFile=hm4, 
> cover=hs14Layer)
> QgsApplication.taskManager().addTask(hs14Task)
>
> while (len([t for t in [ls90Task.status(), ls14Task.status(), 
> hs90Task.status(),
> hs14Task.status()] if t in [QgsTask.Running, QgsTask.Queued]]) > 
> 0)
> and not feedback.isCanceled():
> sleep(1)
>
> if feedback.isCanceled():
> # some cleanup code (send task.cancel() and wait for tasks to terminate)
> break
>
> ls90Result = ls90Task.returned_values
> ls14Result = ls14Task.returned_values
> hs90Result = hs90Task.returned_values   # only this file exists
> hs14Result = hs14Task.returned_values
>
>
> ___
> 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

Re: [QGIS-Developer] How long before closing an issue on "lack of feedback"?

[Nyall Dawson]

On Tue, 14 Aug 2018 at 19:01, Jonathan Moules
 wrote:
>
> Hi Nyall,
>
> Looking at this from another angle (and being aware I know nothing of
> the QGIS code-base) - to me at least that would suggest that maybe it's
> worth improving the crash dumps so that they're better able to be used
> as a stand-alone debugging thing that doesn't require user feedback/insight.
>
> Or alternatively make it clear during the crash dump process that the
> user needs to supply other information beyond just the file.
>

This would certainly help. I'm not sure it's possible, but I'd like to see:

1. A list of all installed/enabled plugins. There's many crash dumps
which point to a plugin being at fault, so it'd be nice to identify
the troublesome plugins.

2. It should be possible to detect crashes coming from Python code, so
we could also do something like disable any python plugins at next
load with a warning that one caused a crash.

3. I'm pretty sure this is impossible - but it'd be fantastic to
include python backtraces whenever a crash occurs from Python.

4. Including anonymized lists of layers loaded and their general
parameters (e.g. provider type) would be beneficial

5. Again, not sure if it's possible, but it'd be great to be able to
block reports which are a crash dump only with no futher info on hub
itself.

Nyall



> Cheers,
>
> Jonathan
>
>
> On 2018-08-14 01:23, Nyall Dawson wrote:
> > On Mon, 13 Aug 2018 at 18:11, Paolo Cavallini  wrote:
> >> I agree, better be conservative. Furthermore, not always lack of feedback 
> >> means an issue is not valid. I'd be against automatically closing the 
> >> issues without further verification.
> > I agree in general, but there's a lot of tickets recently with just a
> > crash dump (with no clues in the dump) and no further info about how
> > to reproduce the crash or what triggered it. These reports don't have
> > *any* value on their own.
> >
> > Nyall
> >
> >> I'm available to help checking, maybe creating a view of tickets needing a 
> >> check could be useful.
> >>
> >> All the best.
> >>
> >>
> >> On 08/13/2018 10:06 AM, Alessandro Pasotti wrote:
> >>
> >>
> >> I would suggest 30 days, people might be so lucky to have their holidays 
> >> last longer than two weeks.
> >>
> >> On Mon, Aug 13, 2018 at 2:23 AM, Nyall Dawson  
> >> wrote:
> >>> Quick question re closing issues on redmine:
> >>>
> >>> What's an "acceptable" amount of time between adding a question to a
> >>> ticket/marking as "feedback" before closing that issue as "Closed due
> >>> to lack of feedback"?
> >>>
> >>> Is 14 days sufficient?
> >>>
> >>> Nyall
> >>> ___
> >>> 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
> >>
> >>
> >>
> >> --
> >> Alessandro Pasotti
> >> w3:   www.itopen.it
> >>
> >>
> >> ___
> >> 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
> >>
> >>
> >> --
> >> Paolo Cavallini - www.faunalia.eu
> >> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> >> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> >>
> >> ___
> >> 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
>
>
> ___
> 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

[QGIS-Developer] ShapeTools News and Updates

[C Hamilton]

ShapeTools for QGIS 3 now has the ability to break lines, along a geodesic
path, into MultiLineString components when they cross the international
date line at -180,180 degrees. This fixes the issue that Anita addresses in
her blog post:

https://anitagraser.com/2011/08/20/visualizing-global-connections/

The ShapeTools 'XY to Line' function has this as an option as well.

Other additions include a new donut shape, the shapes can be drawn as line
strings instead of just polygons, and some of the shapes have been ported
to the processing framework. Eventually all will be in processing.

Calvin
___
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] Running grass algorithms in threads

[Rudi von Staden]

Hi all,

The bottleneck in my script at the moment is the calculation of zonal stats
using 'grass7:r.stats.zonal'. I thought I might speed things up by using
QgsTask.fromFunction() or QgsProcessingAlgRunnerTask() to run these
calculations in parallel. In my tests of both approaches the tasks seem to
complete (task.status() == QgsTask.Complete), but the output file is only
generated for 1 of 4 parallel tasks (the task that finishes first).

I'm assuming this is because grass algorithms are not thread safe? Or am I
missing something in my implementation that could make this work?

Thanks,
Rudi



My code for the QgsTask approach is as below:

def getZonal(task, habitatModelFile, cover):
tempFile = QgsProcessingUtils.generateTempFilename("output.tif")
processing.run("grass7:r.stats.zonal", {
'base':habitatModelFile,
'cover':cover,
'method':5,
'-c':False,
'-r':False,
'output':tempFile,
'GRASS_REGION_PARAMETER':None,
'GRASS_REGION_CELLSIZE_PARAMETER':0,
'GRASS_RASTER_FORMAT_OPT':'',
'GRASS_RASTER_FORMAT_META':''},context=context,feedback=algFeedback)

if task.isCanceled():
deleteFile(tempFile)
return

return tempFile

ls90Task = QgsTask.fromFunction('LS90', getZonal, habitatModelFile=hm1,
cover=ls90Layer)
QgsApplication.taskManager().addTask(ls90Task)
feedback.pushInfo("Calculating LS14 mean...")
ls14Task = QgsTask.fromFunction('LS14 ', getZonal, habitatModelFile=hm2,
cover=ls14Layer)
QgsApplication.taskManager().addTask(ls14Task)
hs90Task = QgsTask.fromFunction('HS90 ', getZonal, habitatModelFile=hm3,
cover=hs90Layer)
QgsApplication.taskManager().addTask(hs90Task)
hs14Task = QgsTask.fromFunction('HS14 ', getZonal, habitatModelFile=hm4,
cover=hs14Layer)
QgsApplication.taskManager().addTask(hs14Task)

while (len([t for t in [ls90Task.status(), ls14Task.status(),
hs90Task.status(),
hs14Task.status()] if t in [QgsTask.Running, QgsTask.Queued]])
> 0)
and not feedback.isCanceled():
sleep(1)

if feedback.isCanceled():
# some cleanup code (send task.cancel() and wait for tasks to terminate)
break

ls90Result = ls90Task.returned_values
ls14Result = ls14Task.returned_values
hs90Result = hs90Task.returned_values   # only this file exists
hs14Result = hs14Task.returned_values
___
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

Re: [QGIS-Developer] How long before closing an issue on "lack of feedback"?

[Paolo Cavallini]

On 08/14/2018 11:21 AM, Matthias Kuhn wrote:
>
> Hi all,
>
> Can a new state "feedback required" be introduced (emphasis on
> required) which then can be closed automatically if no feedback is
> provided? This state would be set by humans when it's clear at the
> time of setting the state that the ticked not only *would like to
> have* but actually *does require* feedback.
>
This sounds reasonable to me. Thanks Matthias.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis

___
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

Re: [QGIS-Developer] How long before closing an issue on "lack of feedback"?

[Giovanni Manghi]

> I agree in general, but there's a lot of tickets recently with just a
> crash dump (with no clues in the dump) and no further info about how
> to reproduce the crash or what triggered it. These reports don't have
> *any* value on their own.
>
> Nyall


By the way, since log we have also a specific query for such tickets:

https://issues.qgis.org/projects/qgis/issues?per_page=200_id=112

as you can see is set to 15 days as it was the agreed period, but if
now the consensus changed we can edit it to a different number of
days.

-- G --
___
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

Re: [QGIS-Developer] How long before closing an issue on "lack of feedback"?

[Matthias Kuhn]

Hi all,

Can a new state "feedback required" be introduced (emphasis on required)
which then can be closed automatically if no feedback is provided? This
state would be set by humans when it's clear at the time of setting the
state that the ticked not only *would like to have* but actually *does
require* feedback.

On another level, there's certainly also potential for improving the
crash handling. It would be great if someone would have the resources to

 * Disable the stack when pdb are not installed

 * Add some guidelines on issue reporting (as stated by Jonathan)

 * Allow opening a new ticket and searching for identical reports to link to

My 2c

Matthias


On 08/14/2018 11:00 AM, Jonathan Moules wrote:
> Hi Nyall,
>
> Looking at this from another angle (and being aware I know nothing of
> the QGIS code-base) - to me at least that would suggest that maybe
> it's worth improving the crash dumps so that they're better able to be
> used as a stand-alone debugging thing that doesn't require user
> feedback/insight.
>
> Or alternatively make it clear during the crash dump process that the
> user needs to supply other information beyond just the file.
>
> Cheers,
>
> Jonathan
>
>
> On 2018-08-14 01:23, Nyall Dawson wrote:
>> On Mon, 13 Aug 2018 at 18:11, Paolo Cavallini 
>> wrote:
>>> I agree, better be conservative. Furthermore, not always lack of
>>> feedback means an issue is not valid. I'd be against automatically
>>> closing the issues without further verification.
>> I agree in general, but there's a lot of tickets recently with just a
>> crash dump (with no clues in the dump) and no further info about how
>> to reproduce the crash or what triggered it. These reports don't have
>> *any* value on their own.
>>
>> Nyall
>>
>>> I'm available to help checking, maybe creating a view of tickets
>>> needing a check could be useful.
>>>
>>> All the best.
>>>
>>>
>>> On 08/13/2018 10:06 AM, Alessandro Pasotti wrote:
>>>
>>>
>>> I would suggest 30 days, people might be so lucky to have their
>>> holidays last longer than two weeks.
>>>
>>> On Mon, Aug 13, 2018 at 2:23 AM, Nyall Dawson
>>>  wrote:
 Quick question re closing issues on redmine:

 What's an "acceptable" amount of time between adding a question to a
 ticket/marking as "feedback" before closing that issue as "Closed due
 to lack of feedback"?

 Is 14 days sufficient?

 Nyall
 ___
 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
>>>
>>>
>>>
>>> -- 
>>> Alessandro Pasotti
>>> w3:   www.itopen.it
>>>
>>>
>>> ___
>>> 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
>>>
>>>
>>> -- 
>>> Paolo Cavallini - www.faunalia.eu
>>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>>> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>>>
>>> ___
>>> 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
>
>
> ___
> 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
>

-- 
Matthias Kuhn
matth...@opengis.ch 
+41 (0)76 435 67 63 
OPENGIS.ch Logo 
___
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

Re: [QGIS-Developer] How long before closing an issue on "lack of feedback"?

[Jonathan Moules]

Hi Nyall,

Looking at this from another angle (and being aware I know nothing of 
the QGIS code-base) - to me at least that would suggest that maybe it's 
worth improving the crash dumps so that they're better able to be used 
as a stand-alone debugging thing that doesn't require user feedback/insight.


Or alternatively make it clear during the crash dump process that the 
user needs to supply other information beyond just the file.


Cheers,

Jonathan


On 2018-08-14 01:23, Nyall Dawson wrote:

On Mon, 13 Aug 2018 at 18:11, Paolo Cavallini  wrote:

I agree, better be conservative. Furthermore, not always lack of feedback means 
an issue is not valid. I'd be against automatically closing the issues without 
further verification.

I agree in general, but there's a lot of tickets recently with just a
crash dump (with no clues in the dump) and no further info about how
to reproduce the crash or what triggered it. These reports don't have
*any* value on their own.

Nyall


I'm available to help checking, maybe creating a view of tickets needing a 
check could be useful.

All the best.


On 08/13/2018 10:06 AM, Alessandro Pasotti wrote:


I would suggest 30 days, people might be so lucky to have their holidays last 
longer than two weeks.

On Mon, Aug 13, 2018 at 2:23 AM, Nyall Dawson  wrote:

Quick question re closing issues on redmine:

What's an "acceptable" amount of time between adding a question to a
ticket/marking as "feedback" before closing that issue as "Closed due
to lack of feedback"?

Is 14 days sufficient?

Nyall
___
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




--
Alessandro Pasotti
w3:   www.itopen.it


___
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


--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis

___
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



___
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

Re: [QGIS-Developer] How long before closing an issue on "lack of feedback"?

[Paolo Cavallini]

On 08/14/2018 02:23 AM, Nyall Dawson wrote:
> On Mon, 13 Aug 2018 at 18:11, Paolo Cavallini  wrote:
>> I agree, better be conservative. Furthermore, not always lack of feedback 
>> means an issue is not valid. I'd be against automatically closing the issues 
>> without further verification.
> I agree in general, but there's a lot of tickets recently with just a
> crash dump (with no clues in the dump) and no further info about how
> to reproduce the crash or what triggered it. These reports don't have
> *any* value on their own.
>
In these cases I'd agree in closing it after 2-4 weeks wiithout further
comments.
My point is that this required human intervention, I do not see a
reliable way of doing it automatically without missing useful info.
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis

___
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