[4000] in Release_7.7_team
FW: Request bug tracking db advice
daemon@ATHENA.MIT.EDU (Mike Nolan)
Sat Aug 30 22:58:11 2003
From: "Mike Nolan" <mknolan@MIT.EDU>
To: <release-team@mit.edu>
Date: Sat, 30 Aug 2003 22:57:03 -0400
Message-ID: <000a01c36f6b$8ea3a920$737ba8c0@Laptop>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
To Whom It May Concern:
Oliver Thomas recommended I ask your advice on bug tracking databases.
We're implementing one for our DOME development at MIT. I'd really
appreciate any thoughts or experience you've had.
Mike Nolan
CADLAB: 617-258-6016
Home: 617-864-5103
mknolan@mit.edu
-----Original Message-----
From: Oliver Thomas [mailto:othomas@MIT.EDU]
Sent: Saturday, August 30, 2003 3:36 PM
To: Mike Nolan
Cc: Oliver Thomas; Susan B. Smullin Jones
Subject: Re: Request bug tracking db advice
Mike,
Susan Jones of MIT's Usability Team forwarded your question regarding a
bug tracking tool to me, presumably because I administer and develop
MIT's Casetracker service (helpdesk ticket tracking). Some suggestions
are in-line below.
On Friday, August 29th 2003 sbjones@mit.edu wrote
> Maybe you could help?
>
> S.
>
>> From: "Mike Nolan" <mknolan@MIT.EDU>
>> To: <usability@MIT.EDU>
>> Subject: Request bug tracking db advice
>> Date: Fri, 29 Aug 2003 14:43:56 -0400
>>
>> Could you pls offer recommendations for a bug tracking database? I'm
>> setting one up in MIT's DOME lab. We'd like a web-based system.
Most people doing bug tracking on campus use bugzilla, Casetracker,
discuss, or something specific to a particular development environment.
Some also use RT (Request Tracker), an open source ticket tracking
tool. Of the above, Casetracker is centrally supported, but bugzilla is
most suited to bug tracking.
>> We don't need anything really fancy - probably just 10 -20 fields, no
>> security other than what's on our DOME server, and a few simply
>> queries.
Depending on what the fields are, Casetracker may work for you. We
cannot currently add fields for individual clients, but if you can use
the existing fields it might work. Casetracker has the additional
limitation that there is no "public" interface. Customers could only
check on their own bug reports, and would have to have MIT
certificates. On the other hand, it's free, pretty well supported, and
will soon (end of fy04) migrate to a more powerful and more
customizable product, allowing custom fields, public
(non-authenticated) access if desired, and so on. Drop me a note if you
want to pursue Casetracker further.
>> We have a couple options we're looking at:
>>
>> - Filemaker Pro through MIT
>>
>> - Bugzilla - open source, probably requires Linux
>>
>> - Develop our own using Dreamweaver, JSP, Apache Tomcat,
>> HQSL or Cold Fusion with MS Access.
Of the above options, I would strongly advise against 1 and 3. Bug
tracking is a known process, and there is little sense in developing
another custom solution, for which you will then have to worry about
on-going development, maintenance, and integration issues. If you want
to go with one of the above three options for internal bug tracking in
your group, I would recommend that you run an instance of bugzilla.
>> I visited N42 and spoke to Barbara. She gave me some advice on
>> Filemaker Pro and also recommended I speak to you.
You may want to ask some of the teams on campus that currently do bug
tracking on a large scale to find out how they do it, and what systems
they use. You may even be able to piggy-back on one of them:
pismere-team@mit.edu (Windows development)
release-team@mit.edu (Athena development)
macdev@mit.edu (Mac OS development)
stellar-dev@mit.edu (Stellar development)
Cheers,
Oliver
