#22 Request Tracker (RT) integration

[Anonymous]

Integration into Request Tracker.

It would be nice if the submission area has more fields
such as priority levels, severity levels, software
version (from CVS?), software component (file, module)
to enter data into.

nprobert@probestar.com

[David Sitsky]

Logged In: YES
user_id=208928

Hi there,

I am not familiar with "Request Tracker", but I am assuming
it is another application for recording tasks/defects
roughly along the line of Bugzilla. Our attitude with
Bugzilla integration is not to replicate information such as
"priority levels", "severity" etc etc in Codestriker, but to
provide a facilty to link to the corresponding record easily
from Codestriker, and to update the task tracking sytsem
record with links to Codestriker.

What I think would be the best approach would be to write a
new "Request Tracker" module, that slots into the system
like the Bugzilla module (see
Codestriker/TopicListeners/Bugzilla.pm). This module gets
topic lifesystem events, which should automatically update
the corresponding "Request Tracker" record with URLs to the
corresponding Codestriker review. Likewise, from
Codestriker, we show links to the corresponding bugzilla
record via the topic properties page.

Is this along the lines of what you meant?

[Nobody/Anonymous]

Logged In: NO

I too agree with the submitters suggestion, and I would
really like something similar in order to integrate with our
home-grown software development system. We have CSCIs
(applications if you will), CSCs (modules), and CSUs
(files). A CSCI is composed of a tree-like heirarchy of
CSCs and the CSUs are the leaves of the tree. We have
design reviews, code reviews, and change reviews of CSUs and
these occur at various stages of development. It would be
nice to be able to create (and subsequently link to) peer
reviews of all of these from within our home-grown system.
At a minimun, we'd need one CSCI, CSC, and CSU field for
each peer review, perhaps another field for the type of
review (design, code & implementation, change). Our
home-grown system is very structured like this, and this is
from where all the peer review links should be visible. Our
home-grown system (or any other system I'd guess) should be
able to get at a unique instance of a peer review based its
own attributes.

I think making the peer review entry form (table) more
configurable like you did with the metrics and comment levels.

Submitted anonymously by deischen@gdeb.com

[David Sitsky]

Logged In: YES
user_id=208928

Hi Dan,

In your case, I would have thought the best of of achieving
this is to write a custom tracker module, similar to the
Bugzilla one. I would prefer to stay on the side of
simplicity, so your "bug id" for a specific review would
look something like:

CSCI=345&CSC=12&CSU=435978 or even just 345:12:435978, or
some other simple ID scheme.

Your module can then do the same lifecycle code as the
Bugzilla module. Even though you have a 3-level ID
heirarchy, it essentially still combines into one tracker ID.

Does that seem workable? I don't see why Codestriker needs
to be aware of the CSCI, CSC and CSU fields, it just needs a
combined ID for linking purposes?

[Nobody/Anonymous]

Logged In: NO

Usurping the bug id doesn't seem like the right thing to do.
First, we use Bugzilla also so that would prevent us from
using this feature for bug tracking. Second, the autobug
tracking module (I forget what its called) that notifies
bugzilla would have to be rewritten or nulled out somehow.

I think a separate field to allow external tools to have
some sort of unique identifier for a peer review topic would
be the way to go. We _could_ use the topic title (e.g.,
topic title = CSCI=345&CSC=12&CSU=435978), but that isn't
very nice to see in emails as the subject.

Our external system/tools don't need to be notified of peer
review events (unlike what the the bugzilla tracker module
does). We just need to be able to record some unique id
into our external tools so that we can later look up the
relevent peer review(s) for a specific unit, change set, etc.

Submitted anonymously by deischen@gdeb.com

[David Sitsky]

Logged In: YES
user_id=208928

Ah I see, you are also using Bugzilla. I wonder then if you
can just define some new topic metrics for CSCI, CSC and
CSU, and enter those into your metrics schema, and enter
them from the "topic information" tab?

[Nobody/Anonymous]

Logged In: NO

Hmm, I suppose you could add a topic metric, but the filters
only allow hours , count, or percent. One could imagine
that our existing system could massage CSCI, CSC, CSU, peer
review type, etc into unique ids, but that's not very
convenient ;-) It also doesn't make it easy to later change
the topic information if the CSU gets renamed or moved to a
different CSC (hopefully our tools would learn to do this
automatically however).

Using topic metrics might make it easy when downloading the
metrics because you could then sort and group by CSCI, CSC,
CSU, etc. Having these identifiers be character strings
would be much easier when looking at the sorted/grouped data
however.

What do I have to do to allow other filters?

[Nobody/Anonymous]

Logged In: NO

The other thing about using the topic metric is that it
isn't set or seen when the topic is created. So in order to
link a topic into our external tools, it would be at least a
2 step process. First you create the topic, then you go to
the topic, visit the topic information page, and enter the
CSC, CSU, etc.
We'd have to write our own "Create Topic" page I guess.

Submitted anonymously by deischen@gdeb.com