Thread: Bug tracking

I have added two new files to the /doc directory called KNOWN_BUGS and
MISSING_FEATURES.  The files say:
PostgreSQL has a single combined bugs, missing features, and todo listsimply called TODO, in this directory.  A current
copyis alwaysavailable on our web site.
 

Part of the problem is that our TODO list really fills all three
functions, and I can understand why some people are not looking in the
TODO files for know bugs or missing feature.

I have no problem if someone wants to set up a more formal bug tracking
system.  Setting up the system is not hard.  It is keeping it
maintained.  Right now, I have a TODO file, and I modifiy it with a text
editor, and run a script that ftp's it to our web site.

I am willing to put that file in a common location so other people can
make changes to the file.  I could check it into the cvs tree every time
as doc/TODO, so anyone with CVS access can make modifications to it.

That may be a very easy way to go.

Right now, I only check it into CVS right before a release, but I can
cvs commit every time a change is made.

Comments?

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Bruce Momjian <maillist@candle.pha.pa.us> writes:
> I have no problem if someone wants to set up a more formal bug tracking
> system.  Setting up the system is not hard.  It is keeping it
> maintained.  Right now, I have a TODO file, and I modifiy it with a text
> editor, and run a script that ftp's it to our web site.

... which is a good low-tech, low-maintenance solution.

> I am willing to put that file in a common location so other people can
> make changes to the file.  I could check it into the cvs tree every time
> as doc/TODO, so anyone with CVS access can make modifications to it.

I think if we do anything at all in this area, we should set our sights
much higher than just opening up the TODO file for community
maintenance.  The bug tracking systems that I've dealt with keep *far*
more than one line of info about each bug.  Ideally, all the info that
you might currently try to find out by digging through the archives of
pgsql-bugs and pgsql-hackers would be in the bugtrack database: original
report, test cases, status, who's working on it, cross-links to similar
bugs, etc.

New-feature requests might be kept track of in the same way, although
I haven't seen anyone using a bugtrack system for that purpose.
        regards, tom lane

On Thu, Jul 01, 1999 at 09:45:13AM -0400, Tom Lane wrote:
> I think if we do anything at all in this area, we should set our sights
> much higher than just opening up the TODO file for community
> maintenance.  The bug tracking systems that I've dealt with keep *far*
> more than one line of info about each bug.  Ideally, all the info that
> you might currently try to find out by digging through the archives of
> pgsql-bugs and pgsql-hackers would be in the bugtrack database: original
> report, test cases, status, who's working on it, cross-links to similar
> bugs, etc.
> 
> New-feature requests might be kept track of in the same way, although
> I haven't seen anyone using a bugtrack system for that purpose.

The Debian bugtrack system is in fact used that way. They've got
a 'severity' field, and one of the severities is 'wishlist'.  (I think
the full list is 'grave', 'important', 'normal', and 'wishlist') The
BTS doesn't have the prettiest web pages, but it seems pretty robust
(lots of Debian users and developers worldwide using it, >40000 bugs
tracked). All functions are handled by parsing emails. In fact, it'd be
straight forward to just continue using the existing email lists, and CC:
the bugtrack system.  That way, the collection of emails discussing a
bug would be archived separately.

the interface is at:

http://www.debian.org/Bugs/

In fact, since there is a Debian PostgreSQL package, maintained by Oliver Elphick (thanks Oliver!), the system's
alreadyavailable:
 

http://www.debian.org/Bugs/db/pa/lpostgresql.html

If the developer's want to try it out, anybody is free to post bugs to
the system, though technically they're out of scope if you're not running
a Debian Linux install. In fact, one 'state' for an open bug is 'forwarded
to upstream developers'.

The whole system is designed around tracking bugs against a collection of
more or less loosely connected packages. The BTS knows about some 'packages'
that aren't actually packages, such as the web site, or the ftp site. There
are facilities for bug maintainence, like reassigning bugs from one package
to another.

Hmm, I've just pulled down and installed the debbugs package - seems to
be a pile-o-perl sort of thing, so it should run on just about any
unix. It's using a flat-file backend (horrors!). Moving to a DB is on
the debbugs TODO. One reason given for putting this package together is
to allow bugs to be filed against it so the developer can keep track
of requested features. Kind of the ultimate in eat your own dogfood,
I suppose.

Ross