[GRASS-dev] Re: GRASS bugs

[Bernhard Reiter]

Am Mittwoch, 2. August 2006 14:37 schrieb Maciej Sieczka:
> Paolo Cavallini napisa?(a):
> > Hi all.
> > I have a slightly different view here: although it is agreed that the
> > bug report is not an advertising tool, it is clear that new and
> > institutional potential users, as well as potential bugfixers, are
> > scared by very long queues of bugs, especially if:
> > - most of them do not have an owner (so one can expect they'll not be
> > fixed soon)
> > - many are very old (> 1 yr, up to > 4yr!).
>
> I agree that the BT is a bit PR tool whether we like it or not...

Partly it is, but the technical values should come first.
It is better to conserve bugs that are not fixed then
to clear them out for marketing purposes.

> > I think the current approach mixes two different needs:
> > - a bug tracking system
> > - a knowledge base.
> > I think it is better to separate more clearly the two.
> > I would therefore suggest to close (as unreproducible/wontfix etc.)
> > *all* old bugs; we should not worry about losing relevant info, because
> > they stay on the database - they just don't show on the usual reports,
> > but can be easily checked and reopened if necessary.

If the stable version is considered stable by many many users
then a clearing policy for old bugs in an old version is fine.
It mostly depends how it is done.

> I could assign 'stalled' to all besides grass6, wish6 and doc*6 tickets.
> Do Others think it would be right?

Depends on the bugs.
What I did in the past sometimes was to ask the original reported
if he or she tried a new version and that we might close the bug report
after a time period, if there is no response.
All if I believed the bug was gone for the new stable series.

> > The best bug reporting tool I'm using is Trac, used eg by qgis:
> > http://svn.qgis.org/trac/report/
> > very easy to use, powerful, and reports can be customized easily. Could
> > we move to this?
>
> (Bernard has recently told that a move to Gforge at
> http://wald.intevation.org/ is planned.)
>
> Bernhard, is there a time schedule for that yet?

No, it depends a bit on me having a time block and feeling comfortable
of having found most issues with large projects on wald already.
Currently I like to fix some things on our installation first.
There is a tracker for the bugs on wald itself.

> How would Gforge compare to Trac?

It is different in a few ways.
A point for Gforge is that many people now the interface from savannah
or similiar services. And it is modular, so that maybe more modules
can be added in the future.

> > I think this should be done before the bugsquishing party, in order to
> > have a more flexible tool and make the work more effective.
>
> I'd would be OK with me *if* moving to another bug tracking system is a
> realistic plan for close future.

I would plan a bugsquishing party indepentely from the bugtracker move,
as the hassles of the tracker are the minor concern.

Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20060802/8d39df96/attachment.bin