P.R. criteria

RT Users
1

Hello, everyone. I am in need of help choosing a problem reporting
and management system. I respect the work done by all the groups I’m
contacting, and I intend to contact more. I appreciate all responses.
The following text is my complete current status. You can find the
HTML version of it at http://mmmgood.via.net. You may prefer the
formatting of the HTML version; it’s easier to read.
I look forward to hearing from you.

Criteria for Problem Reporting Systems
* basics
+ all software involved (interface, main system,
database, etc) must be GPL-compatible unless that
seriously hinders practical selection
+ must have an excellent developer support community,
willing and able to actively accept change requests
and patches. very important.
+ not exclusively oriented on software development.
configurable for all general problem-reporting tasks
+ integrate with source code repository – “what patch
is associated with this bugfix?”
+ integrate with billing system
o lets people buy support
o lets us farm out support
* user interfaces
+ www
+ maybe command line (probably through RDBMS)
+ maybe open standard application like tcl/tk
+ email interface
+ easy enough to use, operable by external parties and
the random public
* database interface options
+ database-neutral (maybe perl-based for DBI)
+ SQL RDBMS
o preferably PostgreSQL because of entirely free
license
o will consider MySQL, due to not entirely free
license
* configuration
+ interface configuration template, for adding new
categories, items, actions, etc
+ dependancy support between tasks

Possible candidates
All candidates from the list at
Best Open Source Mac Software Development Software 2023
, that are at all like free or open source software, will be
evaluated.
* GNATS (http://sourceware.cygnus.com/gnats/), gnatsweb
(http://sourceware.cygnus.com/ml/gnats-announce/1999/msg00
006.html), and wwwgnats
(http://alumni.caltech.edu/~dank/wwwgnats/README.html)
+ fully GPL
+ customizable enough for non-software p.r.'s
+ our developers already have experience with 3.x –
have added credit card support – see
http://www.cyclic.com/cyclic-pages/gnats-ygg.txt
+ its use is depended upon by its own developers –
ideal developer support community
+ all imagined user interfaces, with multiple choices
for www. Do I have the current wwwgnats, as listed
above? I need help in choosing between wwwgnats and
gnatsweb.
+ no RDBMS in 3.x, and I’m not sure about its inclusion
in the future of 4.0
+ well-proven and -understood in general
+ evolving from an older internal structure. arcane
installation and setup. rather unwieldy to new GNATS
admins.
+ I definately need to know the status on the future of
4.0, which is already a usable beta with a CVS
checkin every few days at Cygnus. I’m currently
working on installing it.
* Bugzilla (http://www.mozilla.org/bugs)
+ GPL-incompatible to the point of severe moral
compromise, according to
Various Licenses and Comments about Them - GNU Project - Free Software Foundation. It
states that MPL software can’t link with GPL
software. Alternate viewpoints on this issue are
welcome, as that page is currently my only guide.
+ has inter-item dependancy support
+ massively tested, proven, scalable, stable, etc
+ author support for Bugzilla is barely stated on web
site, and seems to be discouraged.
+ in summary, Bugzilla has major technological
advantages, and major practical disadvantages. It
appears to completely rock.
* Request Tracker http://www.fsck.com/projects/rt/
+ fully GPL
+ uses MySQL, with alleged near future intentions for
other RDBMS’s
+ all necessary user interfaces, with multiple choices
of implementations for some. very smart-looking and
complete www interface.
+ the rate of its support is uncertain. Seems to be a
small developer base, maybe one person, according to
web site. Maturity of product is uncertain to me.
* Frontdesk
+ under investigation
* Front Track
+ unix support lags severely and support is very
expensive. Not a good choice.
* PRepS
+ very good inteface as a Linux/GTK app and www.
+ no email interface
+ purported by author to exist as a subset of GNATS,
where the use of GNATS is recommended if more
functionality is desired. Probably not a good choice
for us.
* Jitterbug / Caretracker
+ Can’t locate the Linuxcare modifications, called
Caretracker. Major recent modifications to
Linuxcare’s web site. No response yet from
Caretracker maintainer David Sifry. Can’t locate any
relevant web sites or mailing lists.

Current Summary

Due to several months of combined team experience with GNATS,
ideal developer community support, and alleged future
features, it is currently a favorite even if it needs
modifications for our ideal use. However, I’d really like to
know that RDBMS support is a near reality, or else that there
will be an easy forward compatibility path with it in the
future. Also we’d like it to be database-neutral, such as with
perl DBI.

Request Tracker and Caretracker (if I could find it) look very
interesting. But can their developers compare to the proven
ambition of GNATS? Problem report systems are very complex and
integral, stressing all infrastructural components and
standards that it’s based on, all the way down to the OS.

What is up with the MPL?

Our team will contribute to any changes that we’d need on any
P.R. system. Please send (or carbon copy) direct advice to
dan_bethe@yahoo.com.

“Don’t expect your own messiah; this neverworld which you desire is
only in your mind.” – http://www.dreamtheater.net/songb4.htm#IV5

Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.

2

Criteria for Problem Reporting Systems
* basics
+ all software involved (interface, main system,
database, etc) must be GPL-compatible unless that
seriously hinders practical selection

GPL as in Gnu Public License? Wouldn’t it be better to say “free”? RT
is.

      + must have an excellent developer support community,
        willing and able to actively accept change requests
        and patches. very important.

I think that applies to the RT community. Well, the split between the
stable version and the development version is uncomfortably big at the
moment, so it’s mostly only me and Jesse that’s working at the development
version. Anyway, we hope to be finished before June with the next stable
release, and I also hope the migration from 1.0 to 2.0 will be painless
for the users. We also hope to have a development version out pretty soon
which can actually be used by those who has the guts for it.

      + not exclusively oriented on software development.

RT is more a request tracker than anything else. It can be used
for bug tracking and project management, but it’s not a good tool for it.
My organization will produce patches making it easy to make links between
RT 2.0 and Bugzilla, and I hope RT 2.2 will pay more attention to bug
tracking.

        configurable for all general problem-reporting tasks

I think RT 1.0 is a good tool for “problem reporting tasks”, though the
configuration could have been more flexible.

RT 2.0 and particularly RT 2.2 will be more flexible and more easy to
hack on and extend with locally developed modules.

      + integrate with source code repository -- "what patch
        is associated with this bugfix?"

RT 1.0 can’t handle that very well. RT 2.0 will have general “links” that
can be used for whatever.

      + integrate with billing system
           o lets people buy support
           o lets us farm out support

RT 2.0 will have a “billing field”. It should be trivial to integrate
with a billing system. The 2.0 code allows site-specific “plugins” to be
executed after a transaction is done. I also hope we can manage to make
links that goes from one RT installation at one site to another RT
installation at another site.

 * user interfaces
      + www
      + maybe command line (probably through RDBMS)
      + email interface

We have those, though I think there might be some bugs with the mailgate
in 1.0. An administrator can also operate it through the DBMS frontend,
though we have admin tools for that (in 1.0 … fixing the admin tools for
2.0 is not our top priority at the moment).

      + maybe open standard application like tcl/tk

Somebody has made an X version that builds on the cli. It’s not unlikely
that we will have an X version that builds on the perl libraries some time
in the future.

      + easy enough to use, operable by external parties and
        the random public

With the admin tools for 2.0 in place in June, it should be pretty easy to
use, yes.

 * database interface options
      + database-neutral (maybe perl-based for DBI)

1.0 is built around mysql, though hacks exists for getting it working with
other DBMS’es, among those PostgreSQL. 2.0 should be neutral, though we
(me and Jesse) will probably only priority that it actually works with
mysql. The problems are just some small differences in the SQL DD syntax
(that is, the database schema might need some modifications), and also a
problem setting and finding the right id at rows (MySQL has
“autoincrement”, probably other DBMS’es have similar systems, but it might
need a tiny amount of porting anyway).

      + SQL RDBMS
           o preferably PostgreSQL because of entirely free
             license
           o will consider MySQL, due to not entirely free
             license

In 1.0, all metadata is stored in the DBMS. In 2.0 all data is stored in
the DBMS.

 * configuration
      + interface configuration template,

Templates are supported for the mail interface, both for 1.0 and 2.0.

The Web UI will be template-based in 2.0.

I’ve never thought of having the CLI template based.

I do have some thoughts about some redesign that might do it easier to
maintain all the UIs when adding functinality to RT, but this won’t come
before earliest 2.2.

for adding new
categories, items, actions, etc

We have easy tools for most of this, more or less … though it will be
more flexible and powerful in 2.0.

We also have a knowledge database which we’re going to link up to RT. I
don’t think the system is working too well at the moment, but I find the
concept behind it very powerful. Locally, we have made the possibility to
link requests to KB items. It’s done very easily when the support worker
knows about the most freqently asked questions (they actually have a
paper list at their desk they can refer to), they just write in a well
known, short tag for the FAQ item, and then they reply semi-automaticly.
That is, a reply consisting of quotes, the standard answer and some
comments is generated, and the support worker just kills off some quotes
and eventually modify the answer a bit. It works like a charm.

      + dependancy support between tasks

We’ve had that internally for a year, almost, and it works like a
charm. 2.0 will have that.

      + the rate of its support is uncertain. Seems to be a
        small developer base, maybe one person, according to
        web site. Maturity of product is uncertain to me.

Argh … that is not up to date :slight_smile:

 * Frontdesk
 * Front Track
 * PRepS

I haven’t heard of those. I’d consider GNATS and Bugzilla as the most
serious competitors at the Bugtracking arena. There is also another
serious competitor at the request tracker arena, but I can’t remember the
name … something with “Stone”, I think.

 * Jitterbug / Caretracker

I think Jitterbug is a very simple tool. I think that GNATS is not very
suitable for tracking external support, but I might be wrong.

Tobias Brox (alias TobiX) - +4722925871 - urgent emails to
sms@tobiasb.funcom.com. Check our upcoming MMORPG at
http://www.anarchy-online.com/ (Qt) and play multiplayer Spades,
Backgammon, Poker etc for free at http://www.funcom.com/ (Java)

3

Hello, everyone. I am in need of help choosing a problem reporting
and management system. I respect the work done by all the groups I’m
. . .

Dan,

Thanks for sharing the results (so far) of your search. You’re welcome
to look at the evaluation grid I did about 4-6 months ago when choosing
our “new” tracking system (we chose RT-1.0, for now). My grid is at:

http://www.cse.ogi.edu/~hakanson/Problem_Tracking_Systems.html

I also recommend an article in the Usenix LISA 99 proceedings. The article
describes REQADM, but has a very comprehensive feature matrix in the back
of it, which will probably give you even more material. The paper is at:

ftp://ftp.intel.com/pub/reqadm/LISA99_Reqadm_paper.tar.gz

Oh, and this paper refers to a mythical tracking system which is
described in RFC 1297, which can be found at:

RFC 1297 - NOC Internal Integrated Trouble Ticket System Functio (RFC1297)

Regards,

Marion Hakanson hakanson@cse.ogi.edu
CSE Computing Facilities

4

Hello, everyone. I am in need of help choosing a problem reporting
and management system.

      + I definately need to know the status on the future of
        4.0, which is already a usable beta with a CVS
        checkin every few days at Cygnus. I'm currently
        working on installing it.

I do believe that you are aware of TkGnats:

http://www.cuug.ab.ca/~macdonal/tkgnats

I do fully intend to write a new version with GNATS v4 support, but I’ve
barely started.

…RickM…

5

Tobias Brox tobiasb@tobiasb.funcom.com writes:

 * Jitterbug / Caretracker

I think Jitterbug is a very simple tool. I think that GNATS is not very
suitable for tracking external support, but I might be wrong.

I think that that is a reasonable statement about GNATS 3 but would
add that there is much better support for it in GNATS 4. Out of the
box I would still recommend RT if you are dealing with support rather
than explicitly bug tracking. GNATS has always been about bug tracking
and while it has become much more general in v4, still has strong
ties to that background.

I always tell people to use RT for request tracking and GNATS for bug
tracking/management. They’re different holes and complexity is reduced
by filling them with different pegs.

IMNSHO of course :slight_smile:

Michael Brader
Aurema Pty Ltd (formerly Softway Pty Ltd)
PO Box 305, Strawberry Hills, NSW 2012, Australia
Email:mbrader@aurema.com, Tel: +61 2 9698 2322, Fax: +61 2 9699 9174

6

How does aurema deal with linking RT and GNATS?
Also, does gnats 4 use a database?On Fri, Mar 24, 2000 at 11:57:23AM +1100, Michael Brader wrote:

Tobias Brox tobiasb@tobiasb.funcom.com writes:

 * Jitterbug / Caretracker

I think Jitterbug is a very simple tool. I think that GNATS is not very
suitable for tracking external support, but I might be wrong.

I think that that is a reasonable statement about GNATS 3 but would
add that there is much better support for it in GNATS 4. Out of the
box I would still recommend RT if you are dealing with support rather
than explicitly bug tracking. GNATS has always been about bug tracking
and while it has become much more general in v4, still has strong
ties to that background.

I always tell people to use RT for request tracking and GNATS for bug
tracking/management. They’re different holes and complexity is reduced
by filling them with different pegs.

IMNSHO of course :slight_smile:

–
Michael Brader
Aurema Pty Ltd (formerly Softway Pty Ltd)
PO Box 305, Strawberry Hills, NSW 2012, Australia
Email:mbrader@aurema.com, Tel: +61 2 9698 2322, Fax: +61 2 9699 9174

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
…realized that the entire structure of the net could be changed to be made
more efficient, elegant, and spontaneously make more money for everyone
involved. It’s a marvelously simple diagram, but this form doesn’t have a way
for me to draw it. It’ll wait. -Adam Hirsch

7

Jesse jesse@pallas.eruditorum.org writes:

How does aurema deal with linking RT and GNATS?

Not at all currently :slight_smile: as our GNATS system (based on GNATS4) is
still pre-production. The new GNATS field definition file will allow
the creation of a “database” which has exactly the same structure as
an RT request which will facilitate the easy transfer from one system
to another. RT2’s flexibility will make this easier as well.

The other (and most important to us) integration we are looking into
is associating requests with problem reports (PRs). When a PR arrives,
it quite often requires several separate tasks to be performed, some
of these will themselves be PRs, but some will be requests, either to
our sysadmins to sort something out, configuration managers to do a
build etc.

My plan is to have two fields within each PR:

Outstanding Requests which will be a list of requests raised as a
result of this PR that are not yet in RT’s resolved state.

CompletedRequests will be a list of requests that are in RT’s resolved
or closed state.

Initially, we’ll put in a cron job which runs through the GNATS
database, checking those lists in each PR and moves requests from one
list to the other as appropriate.

I’m woefully behind on following RT2 development, but a feature which
we’ve added to GNATS4 is the ability to run arbitrary programs when a
field within a PR is changed. If RT had a similar feature (or the
ability to ‘eval’ some arbitrary Perl) when requests are changed, then
I would add a PR field to RT, ensure that it was set correctly when a
request is raised due to a particular PR and then when a requests’
state changes, connect to the GNATS daemon and move that request from
Outstanding to Completed or vice versa, removing the need to monitor
every problem report in GNATS every hour or so.

Associated with this, I’ll probably add hooks into the GNATS web
interface where we can click on the requests in the two fields and be
taken into RT, and vice versa. And add a ‘Create Request in queue’
button to the edit interface.

Also, does gnats 4 use a database?

Not as yet, but the day when someone does the work has been factored
into the design in that if permissions are set up right, access to PRs
has been restricted to a single interface rather than letting anybody
scribble on the report files directly. Basically, take away write
access to the GNATS “database” directory and the only way to modify a
problem report is via the GNATS daemon.

Michael Brader
Aurema Pty Ltd (formerly Softway Pty Ltd)
PO Box 305, Strawberry Hills, NSW 2012, Australia
Email:mbrader@aurema.com, Tel: +61 2 9698 2322, Fax: +61 2 9699 9174

8

I’m woefully behind on following RT2 development, but a feature which
we’ve added to GNATS4 is the ability to run arbitrary programs when a
field within a PR is changed. If RT had a similar feature (or the
ability to ‘eval’ some arbitrary Perl) when requests are changed,

We do, through the Scrips/Action system you can drop in arbitrary
site-specific plugins that are to be executed whenever a transaction is
done…

Tobias Brox (alias TobiX) - +4722925871 - urgent emails to
sms@tobiasb.funcom.com. Check our upcoming MMORPG at
http://www.anarchy-online.com/ (Qt) and play multiplayer Spades,
Backgammon, Poker etc for free at http://www.funcom.com/ (Java)