Front page | perl.qa |
Postings from August 2000
Re: Bug Tracking
From: Richard Foley
August 1, 2000 22:52
Re: Bug Tracking
Message ID: 3987B6B6.6E6466D1@m.dasa.de
Tony Payne wrote:
> > Richard Foley wrote it for us. The source is downloadable from
> > bugs.perl.org.
With a kick-start from Chris Masto and feedback and support from a
lot of people, including Nat (who's done this before).
> > It's been capturing bugs well (modulo the occasional natural hiccups
> > when there's one guy working on it). The new set of bug admins are
> > whittling and pruning the bug list after it was left to grow with years
> > of nobody following up.
And doing a fine job of it too, from 90 percent open to 40 percent of 2000+
bugs in a couple of weeks is not bad. Amazing what a bit of enthusiasm will
> > Richard can describe the features (email controllable this, SQL
> > accessible that, web interface to the other).
> I'm familiar with bugs.perl.org. However, I recall quite a bit of
> discussion on p5p about whether to scrap it for a new system. Since we're
> not directly working on perl 5 here, we have the option to take another
> route. I'm not saying we necessarily should, but we should at least discuss
I guess being familiar with it historically has not always been a bed of
I also realise there are a number of people who feel everything should be
handled by ActiveState, or some other current favourite.
For my part I'd like to say that I don't want to continue to work on any of
this unless a consensus is reached that this would be a good idea. I'm
heartily fed up of taking spurious flak, (valid flak is OK :).
It's mega-frustrating to be at the point where it all runs well, and
after so much work has gone into it, and has a pile of interested enthusastic
administrators/users to have all the effort continually trashed.
I was doing this because no-one else wanted to. Perhaps now is a good time
for me to pass on, at least now there's appear to be lots of willing takers!
Before I do, you should know that there has been positive criticism too
eg: "This is very important work. Thanks!",
(and it was nice to get a 'thumbs-up' from the man himself :)
the next says:
"I come to bury it!"...
In the meantime we now have a bundle of enthusiastic administrators
(firstname.lastname@example.org or email@example.com) who are contributing
to code as well as fixing bug reports (something that few people
have bothered to do in the past, it being seen as low esteem work,
or they're too busy, I guess). Writing a new system is perhaps
seen as high esteem work by comparison and worth the time commitment?
> What are the pros of bugs.perl.org? What are the cons?
It's already written :-)
It supports everything ever asked of it.
It is now robust, with test suites:
All tests successful.
Files=19, Tests=107, 42 wallclock secs (35.58 cusr + 1.12 csys = 36.70 CPU)
Documented (in perldoc -> do what I say _and_ what I do :)
Downloadable open source and data.
All under RCS -> current v2.20.
Integrated with perlbug.
It has a simple (single config file) installation (other people can use it).
Site configurable email newbug recognition and forwarding.
Site configurable scanning of email bodies -> categorisation of reports.
Standard installation*: make; make test; make install.
Multiple interfaces (take your pick):
Web -> search, browse and destroy interface
Tron -> target and mailing list slurper/forwarder
Email 1 -> subject: oriented search, report and admin
Email 2 -> to: oriented report and admin
Command line -> for local db (similar to email)
5+ different formatting types for all discreteobjects are supported across
all outputs for both public and administrative interfaces for:
tickets, messages, patches, notes, users
Differential user/admin help/spec for all formats.
Several utility scripts:
cron.cmd -> regular backup, notification and cleanup jobs
fixit -> fix issues with database inconsistencies, or ever changing
hist.cmd -> slurp data into db from archives
Accepts target mail addresses (and thereby sets category etc) and forwards to
appropriate mailing list/s.
Watches various mailing list for replies to existing tickets to slurp,
checking subject and reply-to, etc.
Defense mechanisms against loops, spam, and other entertaining factors.
Ignores previously seen message-ids, non-relevant mail.
Test targets to email interfaces (dumps header -> originator)
Email interface handles any of the following To lines:
close_<bugid>firstname.lastname@example.org -> ticket admin
busy_win32_install_fatal_<bugid>@bugs.perl.org -> admin
propose_close_<bugid>email@example.com -> ticket admin proposal
note_<bugid>firstname.lastname@example.org -> assign note
patch_<version>_<bugid>_<change_id>email@example.com -> assign a patch
firstname.lastname@example.org -> admin registration request
email@example.com -> admin mail forward
firstname.lastname@example.org -> :-)
Or the following (not very cryptic) Subject lines:
-b original message body search criteria
-q select * from tm_tickets
-H -d2 -l -A close <bugid>+ lib -r patch -e email@example.com
-r pa cl wi -m77 812 1 21 -t 33 -T 34 35 -o -l -d2 -a clo inst <bugid>+ -fA
Auto database dump, email of overview and bugid->admin assignation
Patches can be emailed in -> auto close of ticket
Notes can be assigned from any interface to any ticket
Non-admin emails -> converted to proposals -> mailed to active
Cc: list (and admins) are optionally auto-notified of any status changes to
Relationships between tickets (parent-child) are assignable.
Retrieval of databank via email.
Logging of all activities, admin history tracking.
Graphical display of overview (admins, categories, severity, osname, status).
I think that's more or less all it does for now.
It can't read your mind, or make the tea ;-)
OK, we're now on a stable v2.20 and I'll maintain it until you find a
firstname.lastname@example.org | email@example.com | Richard.Foley@m.dasa.de
'Ciao' - shorter than 'Aufwiedersehen'