Accidently I did some archeological finding.
On http://grass.itc.it/bugtracking/ under "GRASS 5 known bugs list" there is
a link to outdated
http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/BUGS.
I think this link and the site itself should be removed or replaced.
Maciek
On Fri, Feb 18, 2005 at 05:14:27PM +0100, Maciek Sieczka wrote:
Accidently I did some archeological finding.
On http://grass.itc.it/bugtracking/ under "GRASS 5 known bugs list" there is
a link to outdated
http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/BUGS.I think this link and the site itself should be removed or replaced.
Which site?
If you mean freegis.org, we are hosting GRASS' CVS there. 
The link points to a historic file in the grass50 CVS tree.
More seriously, best place for webpages bugs is the weblist.
From: "Bernhard Reiter" <bernhard@intevation.de>
On Fri, Feb 18, 2005 at 05:14:27PM +0100, Maciek Sieczka wrote:
Accidently I did some archeological finding.
On http://grass.itc.it/bugtracking/ under "GRASS 5 known bugs list" there is
a link to outdated
http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/BUGS.I think this link and the site itself should be removed or replaced.
Which site?
If you mean freegis.org, we are hosting GRASS' CVS there.
Sure, delete it and get rid of any backups :).
The link points to a historic file in the grass50 CVS tree.
More seriously, best place for webpages bugs is the weblist.
More seriously - other words:
on the http://grass.itc.it/bugtracking/ there 2 links:
1. http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/BUGS to a very old bug list
2. http://grass.itc.it/bugtracking/bugreport.html to the actuall bugtracking system
This I find incosnistency and potetialy missleading. Shoduldn't the http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/BUGS be replaced with something fresh or removed completely?
I hope I was clear this time.
Maciek
On Sat, Feb 19, 2005 at 01:33:39PM +0100, Maciek Sieczka wrote:
on the http://grass.itc.it/bugtracking/ there 2 links:
1. http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/BUGS to a very
old bug list
2. http://grass.itc.it/bugtracking/bugreport.html to the actuall
bugtracking systemThis I find incosnistency and potetialy missleading. Shoduldn't the
http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/BUGS be replaced
with something fresh or removed completely?
I just removed the link in web CVS, will appear soon.
Thanks for reporting!
Markus: What do you think about updating the BUGS file.
I could basically be emptied leaving a link to the bugtracker
as stable GRASS 5.0 and 5.4 from that cvs module have been released.
At a later point,
we could then use it to collect known bugs that we do not want
to have in the tracker because they only apply to this cvs modules
and are unlikely to get fixed by the main team.
Bernhard
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.
I planned to help with this, but I could not find the time - sorry.
pc
At 11:10, mercoledì 23 febbraio 2005, Bernhard Reiter has probably written:
On Sat, Feb 19, 2005 at 01:33:39PM +0100, Maciek Sieczka wrote:
> on the http://grass.itc.it/bugtracking/ there 2 links:
> 1. http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/BUGS to a very
> old bug list
> 2. http://grass.itc.it/bugtracking/bugreport.html to the actuall
> bugtracking system
>
> This I find incosnistency and potetialy missleading. Shoduldn't the
> http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/BUGS be replaced
> with something fresh or removed completely?I just removed the link in web CVS, will appear soon.
Thanks for reporting!Markus: What do you think about updating the BUGS file.
I could basically be emptied leaving a link to the bugtracker
as stable GRASS 5.0 and 5.4 from that cvs module have been released.At a later point,
we could then use it to collect known bugs that we do not want
to have in the tracker because they only apply to this cvs modules
and are unlikely to get fixed by the main team.Bernhard
--
Paolo Cavallini
cavallini@faunalia.it www.faunalia.it www.faunalia.com
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
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.
I've adjusted this setting a few recent bugs for a start.
Retired "won't fix" wishes/bugs for 5.4 should be included in the 5.4
CVS BUGS file I think.
The Debian bug system has "won't fix" and "unreproducible" tags for bug
status; maybe useful for the GRASS system as well?
Hamish
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.
Retired "won't fix" wishes/bugs for 5.4 should be included in the 5.4
CVS BUGS file I think.
This is what I believe the CVS bug list can be used for.
The Debian bug system has "won't fix" and "unreproducible" tags for bug
status; maybe useful for the GRASS system as well?
I like to switch GRASS's CVS to a new machine somewhere in the future,
then I will also propose a switch to a new issue tracker.
This is a bit away, but I don't think we should make major adjustments
until then as the current tracker basically works and no tracker
will be perfect.
Bernhard
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).
Ideally we need to be able to distinguish between "reported" bugs and
"confirmed" bugs. A confirmed bug would have been confirmed by someone
who knows what they're talking about and would include sufficient
information to be able to reproduce it (either using a standard
dataset or with specified test data).
--
Glynn Clements <glynn@gclements.plus.com>
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
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@fastmail.fm