RT for bug tracking?

RT Users
1

Hi.

I’m evaluating bug-tracking systems, and wondering whether people
use RT for that, as opposed to the trouble ticketing that appears
to be its primary focus.

To be honest, I’m not entirely clear on the difference, except
that in Linas Vepstas’s taxonomy (Call Center, Bug Tracking and Project Management Tools for Linux),
bug tracking systems:
(1) have more roles, states, etc.
(2) enforce workflow (only some transitions are allowed)
(3) can integrate with source-control systems

Well:
(1) Seems easily hackable
(2) Seems counterproductive, at least in a small shop like ours.
I’ve read, and it makes sense, that if a system tries to
enforce a particular workflow, the real world never quite
matches the ideal, and so users have to work around the
system – or worse yet, they give up on it completely
(3) Doesn’t seem to be of great interest here

And on my requirements spreadsheet, RT gets an awful lot of
“yes”'s :slight_smile:

So, I guess my question really is, what is it about RT that makes
it less suitable for bug tracking than are things that bill
themselves as “bug tracking systems”?

Thanks much.

| | /
|-_|/ > Eric Siegerman, Toronto, Ont. erics@telepres.com
| | /
When I came back around from the dark side, there in front of me would
be the landing area where the crew was, and the Earth, all in the view
of my window. I couldn’t help but think that there in front of me was
all of humanity, except me.
- Michael Collins, Apollo 11 Command Module Pilot

2

Hi.

I’m evaluating bug-tracking systems, and wondering whether people
use RT for that, as opposed to the trouble ticketing that appears
to be its primary focus.

Well, here at Best Practical, we find that it makes a pretty good bug
tracking system. (http://rt3.fsck.com login as guest/guest).

that in Linas Vepstas’s taxonomy (Call Center, Bug Tracking and Project Management Tools for Linux),
bug tracking systems:
(1) have more roles, states, etc.
(2) enforce workflow (only some transitions are allowed)
(3) can integrate with source-control systems

Well:
(1) Seems easily hackable

Actually within RT, it should be mostly all configurable. Shouldn’t need
actual hacking.

(2) Seems counterproductive, at least in a small shop like ours.
I’ve read, and it makes sense, that if a system tries to
enforce a particular workflow, the real world never quite
matches the ideal, and so users have to work around the
system – or worse yet, they give up on it completely

I agree completely, though there are ways to ‘lock down’ the workflow
with RT’s roles, scrips and queues.

(3) Doesn’t seem to be of great interest here

But there’s a contributed tool to do it with CVS anyway :wink:

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

3

Eric Siegerman wrote:

So, I guess my question really is, what is it about RT that makes
it less suitable for bug tracking than are things that bill
themselves as “bug tracking systems”?

After I installed RT here the engineering department gave it a look.

Here are their issues with it as a bug system:

  • flat hierarchy. No good way to have groups and then sub-groups.

  • no difference between severity and priority. (yes this can be hacked
    around using custom items but custom fields still feel like a hack to me)

In the end they felt that RT could be made into the system they wanted
or they could just get a system that already did what they wanted.

4

At 04:23 PM 10/24/2003, Eric Siegerman wrote:

So, I guess my question really is, what is it about RT that makes
it less suitable for bug tracking than are things that bill
themselves as “bug tracking systems”?

I guess I wouldn’t be totally loony if I tried comparing RT to a system
like Remedy ARS. With the workflow and custom field improvements in RT3,
the system is flexible enough to do almost anything you want it to. That’s
one of the strengths of Remedy. You can use one tool to build inventory,
asset, bug, support, and new-fangled widget tracking. That kind of
flexibility and workflow support is the direction that RT seems to be
heading in.

The one down side to RT and Remedy is that you need to do the work to get
the tools to your liking. But they are exactly to your liking. Not someone
else’s idea of how your workflow should be. I use RT for bug tracking for
software that I am the sole developer for. I don’t need to have extremely
strict workflow. I don’t need precise differentiation of priority and
severity. But I also use it for project tracking for a larger group. We’ll
probably grow into a change and approval tracking system in the future and
I’m confident that RT will be able to handle it.

Now I’ll admit I haven’t done as much development work on RT as I have
Remedy, but I’ve been much more satisfied as a developer working with RT
and molding it to my needs. I’m looking forward to better Perl support for
Subversion so I can start working on integrating it into my RT bug tracking
workflow.

I hope that helps answer your question, as well as taking care of my desire
to praise Jesse and the other fine contributors to RT.

Michael

Michael S. Liebman m-liebman@northwestern.edu
http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”

5

?b 六, 2003-10-25 10:03, Michael S. Liebman ?g?D?G

Now I’ll admit I haven’t done as much development work on RT as I have
Remedy, but I’ve been much more satisfied as a developer working with RT
and molding it to my needs. I’m looking forward to better Perl support for
Subversion so I can start working on integrating it into my RT bug tracking
workflow.

Maybe a bit OT, but my colleague Chia-Liang Kao (clkao) has developed a
set of very useful Perl modules, including:

  • SVN::Core
    Perl binding for subversion, merged as subversion/bindings/swig/perl/
    inside the svn distribution
  • SVN::Simple (simple API to libsvn)
  • SVN::Web (cvsweb-workalike)
  • SVN::Mirror (copy between svn repositories)
  • VCP::dest::svn (incrementally import cvs/p4/sourcesafe into svn)
  • svk (subversionkeeper, a bitkeeper clone on top of svn)

I think most of them are on CPAN now. If you are interested, contact
clkao@clkao.org for details. :slight_smile:

Thanks,
/Autrijus/

signature.asc (187 Bytes)

6

?b 六, 2003-10-25 10:03, Michael S. Liebman ?g?D?G

Now I’ll admit I haven’t done as much development work on RT as I have
Remedy, but I’ve been much more satisfied as a developer working with RT
and molding it to my needs. I’m looking forward to better Perl support for
Subversion so I can start working on integrating it into my RT bug tracking
workflow.

Maybe a bit OT, but my colleague Chia-Liang Kao (clkao) has developed a
set of very useful Perl modules, including:

  • SVN::Core
    Perl binding for subversion, merged as subversion/bindings/swig/perl/
    inside the svn distribution
  • SVN::Simple (simple API to libsvn)
  • SVN::Web (cvsweb-workalike)
  • SVN::Mirror (copy between svn repositories)
  • VCP::dest::svn (incrementally import cvs/p4/sourcesafe into svn)
  • svk (subversionkeeper, a bitkeeper clone on top of svn)

I think most of them are on CPAN now. If you are interested, contact
clkao@clkao.org for details. :slight_smile:

Thanks,
/Autrijus/

signature.asc (187 Bytes)

7

Here are their issues with [RT] as a bug system:

  • flat hierarchy. No good way to have groups and then sub-groups.

Hmmm. RT has subroups of user-defined groups (i.e. ultimately of
users), and it has the child/parent grouping for tickets. So I’m
not sure which sort of object they’re talking about as having a
flat hierarchy. Could you elaborate?

In the end they felt that RT could be made into the system they wanted
or they could just get a system that already did what they wanted.

That’s always the dilemma, isn’t it? So, what did they end up
choosing instead?

| | /
|-_|/ > Eric Siegerman, Toronto, Ont. erics@telepres.com
| | /
When I came back around from the dark side, there in front of me would
be the landing area where the crew was, and the Earth, all in the view
of my window. I couldn’t help but think that there in front of me was
all of humanity, except me.
- Michael Collins, Apollo 11 Command Module Pilot

8

I believe Sean is referring to not being able to have a parent-child
relation with groups, as we can with tickets. I think the question is one
of privilege inheritance, which in RT is only three levels deep (and hard as
all get-out to figure out, too).

You can have pseudo-subgroups by assigning a user to two or more different
groups with “cascading” privileges (ie, one group has admin privileges, one
group has queue admin privileges, one group contains standard users, etc.)From: Eric Siegerman [mailto:erics@telepres.com]
Sent: Monday, October 27, 2003 4:34 PM
To: rt-users@lists.fsck.com
Subject: Re: [rt-users] RT for bug tracking?

Here are their issues with [RT] as a bug system:

  • flat hierarchy. No good way to have groups and then sub-groups.

Hmmm. RT has subroups of user-defined groups (i.e. ultimately of
users), and it has the child/parent grouping for tickets. So I’m
not sure which sort of object they’re talking about as having a
flat hierarchy. Could you elaborate?

In the end they felt that RT could be made into the system they wanted
or they could just get a system that already did what they wanted.

That’s always the dilemma, isn’t it? So, what did they end up
choosing instead?

| | /
|-_|/ > Eric Siegerman, Toronto, Ont. erics@telepres.com
| | /
When I came back around from the dark side, there in front of me would
be the landing area where the crew was, and the Earth, all in the view
of my window. I couldn’t help but think that there in front of me was
all of humanity, except me.
- Michael Collins, Apollo 11 Command Module Pilot

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

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

9

Eric Siegerman wrote:

Here are their issues with [RT] as a bug system:

  • flat hierarchy. No good way to have groups and then sub-groups.

Hmmm. RT has subroups of user-defined groups (i.e. ultimately of
users), and it has the child/parent grouping for tickets. So I’m
not sure which sort of object they’re talking about as having a
flat hierarchy. Could you elaborate?

They are currently using bugzilla and have been for about 2 years. They
are accustomed to groups of projects with sub-projects. Makes it easier
to assign the bug to the right place.

System → subsystemA, subsystemB, etc.

All I could see in RT was the flat queue structure.

In the end they felt that RT could be made into the system they wanted
or they could just get a system that already did what they wanted.

That’s always the dilemma, isn’t it? So, what did they end up
choosing instead?

They are still using bugzilla but are looking at other alternatives.

10

Eric Siegerman wrote:

Here are their issues with [RT] as a bug system:

  • flat hierarchy. No good way to have groups and then sub-groups.

They are currently using bugzilla and have been for about 2 years. They
are accustomed to groups of projects with sub-projects. Makes it easier
to assign the bug to the right place.

System → subsystemA, subsystemB, etc.

All I could see in RT was the flat queue structure.

Are you saying that Bugzilla provides simple ways to set ACLs at the
sub-project level? That’s actually interesting, if it’s the case.

When I’ve played with bugzilla, all I’ve seen is the semi-hardcoded
“Component” field, which has felt largely identical to an RT custom
field. What does it get you that I’m missing?

-jesse
11

Jesse Vincent wrote:

All I could see in RT was the flat queue structure.

Are you saying that Bugzilla provides simple ways to set ACLs at the
sub-project level? That’s actually interesting, if it’s the case.

When I’ve played with bugzilla, all I’ve seen is the semi-hardcoded
“Component” field, which has felt largely identical to an RT custom
field. What does it get you that I’m missing?

-jesse

On a ticket in our bugzilla I see:

Product
Component
Status
Platform
OS
Version
Priority
Severity
Milestone
Reporter
Assigned To
Summary
Keywords

and then the history.

The product and component are the project / sub-project level I was
referring to.

As I said in my initial mail to this thread, RT can probably recreate
everything we have in bugzilla. However, engineering sees no benefit to
taking the time to modify and tweak RT just to get it to the state
bugzilla is at.

Oh yeah, I remember the other complaint. The priority in RT is defined
by numbers which have no intrinsic meaning. They preferred the
high,medium,low (and minor, serious, showstopper) style of bugzilla and
other bug systems.

Meanwhile RT solves the needs of IT quite well and we are happy.

12

On a ticket in our bugzilla I see:

Product
Component
Status
Platform
OS
Version
Priority
Severity
Milestone
Reporter
Assigned To
Summary
Keywords

and then the history.

The product and component are the project / sub-project level I was
referring to.

nod The RT philosophy is very much that every site wants different
metadata, so our custom fields are just that–custom. They’re designed
to be easy to add and change as your workflow changes. It’s not really
something that requires “modifying” so much as simple point and click
configuration.

Oh yeah, I remember the other complaint. The priority in RT is defined
by numbers which have no intrinsic meaning. They preferred the
high,medium,low (and minor, serious, showstopper) style of bugzilla and
other bug systems.

nod Again, this is a case where a “Severity” custom field with a
drop-down list of your set of priorities would work nicely. there’s
no reason you have to use the built-in integer priority system at all.

All that being said, if they’re happy with bugzilla, they’re happy with
bugzilla. There’s no need to move away from a system that meets all of
your needs.

Meanwhile RT solves the needs of IT quite well and we are happy.

I’m glad. :slight_smile:

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

13

On a ticket in our bugzilla I see:

Product
Component
Status
Platform
OS
Version
Priority
Severity
Milestone
Reporter
Assigned To
Summary
Keywords

and then the history.

The product and component are the project / sub-project level I was
referring to.

nod The RT philosophy is very much that every site wants different
metadata, so our custom fields are just that–custom. They’re designed
to be easy to add and change as your workflow changes. It’s not really
something that requires “modifying” so much as simple point and click
configuration.

Oh yeah, I remember the other complaint. The priority in RT is defined
by numbers which have no intrinsic meaning. They preferred the
high,medium,low (and minor, serious, showstopper) style of bugzilla and
other bug systems.

nod Again, this is a case where a “Severity” custom field with a
drop-down list of your set of priorities would work nicely. there’s
no reason you have to use the built-in integer priority system at all.

All that being said, if they’re happy with bugzilla, they’re happy with
bugzilla. There’s no need to move away from a system that meets all of
your needs.

Meanwhile RT solves the needs of IT quite well and we are happy.

I’m glad. :slight_smile:
I think a bugzilla2rt tool would be very useful in helping people
migrate to rt.