Anybody integrated a 3rd party problem tracking tool to Perforce?

[Brad_Appleton-GBDA001@email.mot.comBrad_Appleton-GBDA001]

softweyr at xmission.com writes:
> No, but I've often considered developing one - a problem tracking
> partner for Perforce.  Quite a good idea, isn't it?  I like the
> simplicity and speed of Perforce; a problem tracking system with those
> same features would be nice to have.
> 
>  > Is the review daemon or the API the best solution?
> 
> Depends on exactly how to want to implement your "integration."  Unless
> you're writing C or Perl functions, the API is probably out of bounds,
> which leaves you with the review daemon.

Rumor has it that Problem Tracking system development/integration is
one of the top items on the "TO DO" list for PerForce Software. For
those of us that need/want such a tracking system, perhaps it would be
best if we simply let the PerForce team know our "wish list" for such
a beast. (I'll go first :-)

I would want the following in a tracking system:

  * Year 2000 Compliance

  * A Web interface (preferably one with dynamic capabilities rather
    than strictly "static" stuff like in CGI scripts) that used existing
    configuration info instead of requiring me to create and maintain
    two sets of config-files for the same purpose but for different
    interfaces.

  * The ability to plug it into a commercial database (perhaps a standard
    RDBMS or ODBMS) if so desired. A mechanism for supporting SQL or OQL
    queries would be fantastic (in addition to a regular command with
    various options to create and format queries/reports/metrics).

  * The ability to configure/extend/integrate it at various levels:
      1. at a source code API level

      2. at a programming language level -- perhaps using a script-like
         language to program the content and appearance of the various
         forms or classes of forms. Tcl, Perl, and Python are easily
         embeddable for this purpose these days, so one neednt reinvent
         a whole new language (e.g. the UIL stuff used by Motif)

      3. at the GUI level -- the most convenient way to compose the
         content and appearances of forms (without having to learn
         a scripting language). Note that I still want #2 above however
         so that I have a non-GUI way of doing it, and (more importantly)
         a non-interactive way of doing it that may be automated by my
         own scripts which are specific to my work environment.

   * The ability to define several different classes of forms, so Im not
     stuck with trying to force-fit the same form for the purposes of
     tracking different things like: customer call tracking, bugs/fixes,
     enhancements, initial development tasks (before I have a baseline
     to "enhance"), integration/building, project risks, and any other
     issue or activity. Of course, there would need to be "prepackaged"
     classes for the most common uses: defects, change-requests,
     call-tracking. It would also be nice if there was some mechanism
     for me to share/inherit things common to several classes, so I wouldnt
     have to expend extra effort to create and maintain redundant info.

   * The ability to define *projects*, logically distinct groupings of
     records (perhaps from the same class, or for different classes)
     so I can categorize/view bugs for projectA separate from projectB.
     I would also need the ability to define a "project" that might cut
     across several "classes". This way, I can have a single project
     that contains all the defects and change-requests for the same
     product (this might be a accomplished by permitting projects to
     contain subprojects).

   * The ability to define, not only my own fields and field values, but
     also my own set of states and state transitions.

   * The ability to define pre-event and post-event trigger operations for
     those state transitions.

   * The ability to link records together, so I can have "sibling" defects,
     and even parent/child defects. This will allow me to impose a
     hierarchical structure on defects and changes if I so choose. If I
     do this, it would be nice if I could specify that certain operations
     should happen to an entire group (perhaps closing a bug-report closes
     all of its children too).

   * A way to let PerForce "automagically" know which defect Im am working
     on for a given checkin/checkout (perhaps in a particular directory).
     This would be a good candidate to associate with a PerForce "job".

   * Speaking of "jobs", that would be one of the most important things to
     be able to communicate/integrate between P4 and the tracking system.

   * Performance is less important to me for the tracking system, at least
     for those operations which are typically interactive and dont need to
     happen faster than human hand/eye coordination can accommodate. The
     most important areas for "speed" would be:
         - performing a query/sort of records
         - performing an operation which involves communication
           between P4 and the tracking system (modulo any triggers
           I might impose myself of course). For example, I might
           want checkins/checkouts/merges to be logged in the defect
           record somehow.

   * The ability to associate "attachments" with a record. This would
     be more than just any old multi-line text field or text file. I
     might have an MS-Word document or Excel Spreadsheet or some other
     NON-plaintext document or datafile. Just like the good "email"
     programs and WWW browsers, I could set-up which programs or
     "plug-ins" to use for viewing/creating/editing various kinds of
     attachments. I dont know if MIME format would be necessary here,
     but certainly P4 is already capable of storing such attachments

That said, my choice for programming such a tracking system would
probably be Java. It has a well-defined JDBC database standard, a
standard interface for calling C/C++ code (and soon Tcl, or so I
hear), dynamic internet content, WWW access, and portability (yeah -
we all know its not quite as portable across different window systems
as is hyped - instead of "write once, run anywhere" its really more
like "write once, debug everywhere" :-)

Cheers!
- -- 
Brad Appleton <bradapp at enteract.com> | http://www.enteract.com/~bradapp/
 "And miles to go before I sleep."   |  3500+ WWW links on CS & Sw-Eng