[cvsnt] Bug tracker

[commedo]

I used "BUGS - Bug genie" (http://bugs-bug-genie.sf.net). You may look for
this as altenative.

regards,


commedo 

-----Original Message-----
From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of
Gerhard Fiedler
Sent: Kamis, 12 Mei 2005 06:38 comm
To: cvsnt at cvsnt.org
Subject: [cvsnt] Bug tracker

Luigi D. Sandon wrote:

>> and was a maintenance headache. But no matter which tool you use, it's
>> no better than *how* you use it of course.
> 
> I guess Tony alone can't handle everything :-) We're using Mantis too from
> some time now with excellent results, however using it inside a company is
> very different than using open to everybody.

I'm also using Mantis, and IMO it is quite stable and doesn't need more
maintenance than organizing the bug reports needs anyway.

> Maybe with a group of experienced user with enough time to verify and
> filter the bugs in the database it could work - but could be a problem
> to "mantain" too many releases - they should be "reduced" to a few ones,
> even many seem to be still using very "old" releases. 

The guy who writes the news reader 40tude Dialog uses Mantis to maintain a
public list of bugs and enhancement requests:
http://40tude.com/dialog/mantis/

This seems to work well. Apparently a few experienced and dedicated users
help out as Mantis admins, but everybody can add new entries and add
comments to existing entries.

I agree that the release management needs a bit of thought. There possibly
could be two different projects in Mantis: one for the development releases
that doesn't really associate bugs to releases (and possibly has some
access restrictions), and one for the stable releases, where bugs are
associated to a specific release and that allows the public to report bugs.

> Or just some selected users should be allowed to "move" bugs from the
> mailing list to the database - again, it's a task requiring time and
> some systems to verify the bugs.

I don't think that this makes sense. Why not allow the reporter himself to
add the bug to the database? If it's bogus, it's easy to remove. If it's
not -- and that will be the majority of cases --, this saves a lot of time
for the admins; it may only need some adjustments (categorization,
priorization, clarification, ...).

Gerhard