[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