[GRASS5] outdated Grass5 bugs list

Jean-Denis Giguere jdenisgiguere at fastmail.fm
Mon Feb 28 09:49:06 EST 2005


Markus Neteler wrote:
> On Mon, Feb 28, 2005 at 11:02:40AM +0100, Bernhard Reiter wrote:
> 
>>On Thu, Feb 24, 2005 at 11:53:37AM +1300, Hamish wrote:
>>
>>>>I vote (for what it's worth) for removing as many bugs as possible
>>>>from the  list; most of them do not apply anymore, and give new user a
>>>>very bad  impression. Furthermore, it is difficult to find "real" bugs
>>>>now.
>>>
>>>
>>>WRT bugs in the bug tracker, we could make better use of the priority
>>>settings to sort out the important bugs from two year old bugs that only
>>>turned up on one guy's Amstrad somewhere down in New Zealand (which is
>>>probably just a misconfiguration on his system anyway).
>>>
>>>AFAI understand, 100 is super critical and 0 means don't worry about it.
>>
>>Yes, the priority could be utilised a lot more.
> 
> 
> To be honest: who cares? There are more than 15 reports with 70 priority,
> some of them in RT for more than one year.
> 
> Just my 0.02 Euro
> 
> Markus

Maybe priority is just significative when you have a first sort system. 
If you let the user set the priority of its bug, it won't be really 
representative of the effort that the community should put to resolve 
it. But, if you let people create bugs with status "new" and developer 
change status to "open" when it is validated, you have a good occasion 
to put an appropriate priority fixed.

I think that the Mapserver team do very well in bug tracking. Bugzilla 
is certainly a powerful tool for this task,but I don't think it is 
necessary as long as the whole community have good practice concerning 
this important part of the development cycle. These are some reasons 
that may explain their success :

1. You have to choose a componant of the software when you create the 
bug. (ex. PostGIS interface) Each bug is cc to developer dealing with 
this componant.

2. The bugs are created with status:new. If nobody open it before few 
weeks, you know that bug is dead. You can easily tag it to won't fix or 
invalid.

3. Reporter is in cc of its bug. If the bug report is not correct, 
developer can tag it invalid so the person that enter the bug report can 
improve it and put its status to new.

4. You can tag a target milestone to the bug, if we passed the milestone 
but don't correct the bug, you have to choose if we report te milestone 
or if we drop the bug.


Also, we should put a link to the bugzilla Bugs Writing Guidelines 
(http://www.mozilla.org/quality/bug-writing-guidelines.html) in the 
grass bug report page. This may improve quality of bug report.

I don't give so much time to GRASS community by now, so consider this as 
a 1/2 canadian cents... ;-)

Jean-Denis

-- 
Jean-Denis Giguère
Étudiant en géomatique
appliquée à l'environnement
Stagiaire à l'Agence de développement
de réseaux locaux de services de santé
et de services sociaux de l'Estrie
Tél. 829-3400 42008
Courriel. jdenisgiguere at fastmail.fm




More information about the grass-dev mailing list