Re: Bug tracking (was Re: +/- Inf for float8's)

Perhaps this is foolhardy, but it might be worth making a list of
requirements, at least so we can tick moxes when considering any system...


>(a) a bug *tracking* system is not the same as a bug *reporting*
>system.  A tracking system will be useless if it gets cluttered
>with non-bug reports, duplicate entries, etc.  There must be a human
>filter controlling what gets entered into the system.

1. Human filtering of 'incoming' reports.

2. Separation of 'bug reports' from 'bugs'. 


>(b) our previous try (with Keystone) was a failure in part because
>it was not even effective as a bug reporting system: it did not
>encourage people to fill in our standard "bug report form", with the
>result that bug reports were seriously incomplete w.r.t. version
>numbers, platforms, etc.  This is a relatively simple technical
>deficiency, not a social-engineering problem, but it does point up
>the fact that one-size-fits-all solutions fit nobody.

3. Web and email submissions should do data verification and reject
incomplete reports (giving reasons).


>(c) fill-in-the-web-form reporting systems suck.  They make it
>difficult to copy-and-paste query output, dump files, etc.
>Also, the window for entering text is always either too small or too
>large.  Email with attachments is fundamentally superior.

[I disagree with the above (web *can* work), but...]

4. Must support email AND web submissions, or at least email submissions
and web reporting.


>(d) divorcing the bug reporting system from the existing mailing
>list community is foolish, as Thomas pointed out. 

5. Must integrate with mailing lists.


And to add some of my own (suggested) requirements:

6. Require: name, email address, OS & version, PG version, short description.

7. Optional: compiler & version, long description, file attachments.

8. Creation of 'bug reports' is a public function. Creation of 'bug
entries' is a priv'd function.

9. Simple reporting - unprocessed bug reports, open bugs, bugs by module etc. 


I have tried to keep this relatively simple in an effort to define what we
need to make it work in the current context. But I'm sure I've missed
things.... 


<YABRS>
As it happens, I have a Perl/PGSql based bug-tracking system that I give my
clients access to, which does about 80-90% of this, and I would be willing
to GPL it.

Before anybody asks, the reason I rolled my own was because there weren't
many that supported email and web submission, and the ones that did, did
not support PG easily. This system also implements my prefferred model for
bug reporting which is to separate (to use my terminology) 'Incidents' from
'Issues': an Incident is an event (or set of events) that causes a user to
make a report. An Issue is an individual item that needs attention (usually
a single bug). Typically users send email (or web forms) and I create one
or more Issues. When two Incidents (bug reports) are made about the same
Issue, then the system allows the two to be linked, so that when the Issue
is fixed, all Incident owners are notified etc.

The email integration does very little validation, and it is *not*
integrated with a mailing list (but it is on my ToDo list). I had planned
to do the following:

- When a message is received and the subject does not start with 'Re:' (or
'Aw:'!), submit it as a bug report. If the bug report code returns an
error, then reject it from the list. If the bug report works, then send it
on to Majordomo & Mhonarc.

- If the message starts with 'Re:' then just submit it to the list.

Let me know if anyone would be interested, and I can set up a sample
'product' for people to play with and then, if it is still worth pursuing,
make the code a little more presentable (and decrease it's reliance on my
own perl libraries).

Bear in  mind that this is designed for an Apache/mod-perl environment, so
may not be acceptable to some people. 
</YABRS>



----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/