PRM - Problem Report Manager

The Problem Report Manager (PRM) is a system for managing problem reports (PRs) pertaining to some other system, hereafter known as "the product", and originating from users of the product, hereafter known as "customers". When a customer has a problem with the product, he sends an electronic mail message to a support site. There, the tool prm_receive turns this message into a PR by adding some data to it, records it in a database made using the tool prm_make, and distributes it to a group of maintainers. Using the tool prm, one of the maintainers accepts responsibility for the PR, deals with the problem, and retires the PR when the problem is dealt with. Along the way, memos may be appended to the PR, and responsibility for the PR may be transferred from one maintainer to another. The PR database may be queried about the histories of PRs and about which PRs are known, which are pending or have been accepted or retired by whom, and which are older than some age.

E.g., suppose a customer Wally at Podunk University has a problem with the product foo. He sends a message:

wally% mail -s "glorp bug" foo-bug@fooinc.com I did "glorp argh" and nothing happened! ^D wally% PRM receives this at the support site Foo, Inc. Moments later, the maintainers receive the following (modulo additional header data generated by the electronic mail system): To: foo-bug@fooinc.com Subject: glorp bug Date: Fri, 11 Mar 1994 13:00:00 CST From: Wally Awful Resent-To: foo-bug-dist@fooinc.com Resent-Date: Fri, 11 Mar 1994 13:00:30 CST Resent-From: daemon@fooinc.com (PRM) LABEL: 42 (PRM) RECEIVED: Fri 11 Mar 94 (PRM) STATUS: pending (PRM) RESPONSIBLE: I did "glorp argh" and nothing happened! Lines of the form "(PRM) ..." have been added by PRM. The first added line says this PR has been assigned label 42. Each PR is assigned a unique label, which happens to be a natural number. All operations on a PR refer to it by label. The second added line gives the receipt date, which may differ from the sending date appearing in the header. The third and fourth added lines say this PR is pending, i.e., nobody has accepted responsibility for it yet. When somebody does, its STATUS will change to accepted and its RESPONSIBLE to the name of that somebody. Later, when the PR is retired, its STATUS will change to retired. Now suppose a maintainer Tom decides to deal with the glorp bug: tom% prm accept 42 tom% And further suppose some other maintainer Kim, not knowing Tom has already accepted this PR, also decides to deal with it: kim% prm accept 42 prm: PR 42 is not pending kim% To find out what is going on, Kim queries the history of the PR: kim% prm history 42 (PRM) HISTORY: 13:31 Fri 11 Mar 94: accepted by tom (PRM) HISTORY: 13:05 Fri 11 Mar 94: created kim% At this point, various scenarios are possible. E.g., suppose Kim really wants this one, she and Tom discuss it, and they agree Kim should take it. They transfer responsibility for the PR from Tom to Kim in two steps. First, Tom unaccepts the PR: tom% prm unaccept 42 tom% Second, Kim accepts the PR, which she can do now, because it is pending again: kim% prm accept 42 kim% Etc.

The most important motivation for PRM is to address a problem common at support sites: somebody sends a message reporting a problem to a group of maintainers, each of whom assumes some other maintainer is going to take care of it. PRM makes it easy to find out about PRs that have been around for a while and are still pending. E.g., to get a list of PRs that are still pending after three days, do the following:

% prm pending_after 3 This could be done automatically, e.g., once per day (using cron) and a message sent to an administrator if the list is nonempty.

NOTES

PRM bears some resemblance to GNATS, the GNU Problem Report Management System, but it is considerably less complex and formal. E.g., in PRM, customers send ordinary electronic mail messages, whereas in GNATS, they send messages created using a utility that must be distributed with the product. PRM is probably adequate for a research product with academic customers, while GNATS may be preferable if the volume of messages or the number of maintainers is large.

Source Code

Source code is available from our ftp-area.

AUTHOR

Ralph Clarke Haygood, rch@sics.se