[GRASS-dev] Re: GRASS bugs

[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...

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

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

> 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?

How would Gforge compare to Trac?

> Qgissers have done he transition not long ago, so they
> could give us hints if necessary. A trac package is present eg in
> Debian, so installation should pose no major problems.

I personally don't like Trac's WIKI like format; it makes reporting bugs
over complicated, which might scare off naive users. The WIKI formatting
should be only an addition to allow formatting when needed. It should
not not the requirement only to fill in a 10 word report.

> 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'm ready to cooperate on this.

Maciek

P.S.

Let's hold off planning the bug fiest schedule until the issues here are
sorted out.