The following fields are present whenever a PR is submitted using send-pr. PRMS adds additional fields when the PR arrives at the Support Site; explanations follow.
>Submitter-Id:
(Text)
A unique identification
code assigned by the Support Site. It is used to identify all Problem Reports
coming from a particular site. (Submitters without a value for this field
can invoke
>Originator:
(Text)
Originator’s real
name. The default is the value of the originator’s environment variable
NAME.
>Organization:
(MultiText)
The originator’s organization. The default value is set with the variable,
DEFAULT_ORGANIZATION,
in the send-pr
shell script.
>Confidential:
(Enumerated)
Use of this field depends on the originator’s relationship with the support
organization; contractual agreements often have provisions for preserving
confidentiality. Conversely, a lack of a contract often means that any
data provided will not be considered confidential. Submitters should be
advised to contact the support organization directly if this is an issue.
If the originator’s relationship to the support organization provides for confidentiality, then if the value of this field is ‘yes’ the support organization treats the PR as confidential; any code samples provided are not made publicly available (e.g., in regression test suites). The default value is ‘yes’.
>Synopsis:
(Text)
One-line summary of the problem. send-pr
copies this information to the ‘Subject:’
line when you submit a Problem Report.
>Severity:
(Enumerated)
The severity of the problem. Accepted values include the following input:
critical
The product, component
or concept is completely non-operational or some essential functionality
is missing. No workaround is known.
serious
The product, component
or concept is not working properly or significant functionalit
ffb
y is missing.
Problems that would otherwise be considered ‘critical’
are rated ‘serious’
when a workaround is known.
non-critical
The product, component
or concept is working in general, but lacks features, has irritating behavior,
does something wrong, or doesn’t match its documentation.
The default value is ‘serious’.
>Priority:
(Enumerated)
How soon the originator requires a solution. Accepted values include the
following input:
high
A solution is
needed as soon as possible.
medium
The problem should
be solved in the next release.
low
The problem should
be solved in a future release.
The default value is ‘medium’.
>Category:
(Text)
The name of the product, component or concept where the problem lies. The
values for this field are defined by the Support Site.
>Class:
(Enumerated)
The class of a problem uses one of the following as input:
sw-bug
A general product
problem. (‘sw’
stands for software.)
doc-bug
A problem with
the documentation.
change-request
A request for
a change in behavior, etc.
support
A support problem
or question.
duplicate
(pr-number)
Duplicate PR.
pr-number should
be the number of the original PR.
The default is ‘sw-bug’.
>R ffb elease:
(Text)
Release or version number of the product, component or concept.
>Environment:
(MultiText)
Description of the environment where the problem occurred: machine architecture,
operating system, host and target types, libraries, pathnames, etc.
>Description:
(MultiText)
Precise description of the problem.
>How-To-Repeat:
(MultiText)
Example code, input, or activities to reproduce the problem. The support
organization uses example code both to reproduce the problem and to test
whether the problem is fixed. Include all preconditions, inputs, outputs,
conditions after the problem, and symptoms. Any additional important information
should be included. Include all the details that would be necessary for
someone else to recreate the problem reported, however obvious. Sometimes
seemingly arbitrary or obvious information can point the way toward a solution.
See Helpful hints.
>Fix:
(MultiText)
A description of a solution to the problem, or a patch which solves the
problem. (This field is most often filled in at the Support Site; we provide
it in case the submitter has solved the problem.)
PRMS adds the following fields when the PR arrives at the Support Site:
>Number:
(Enumerated)
The incremental identification number for this PR.
The ‘>Number:’ field is often paired with the ‘>Category:’ field in subsequent email messages as in the following input.
category/number
This is for historical reasons, as well as because Problem Reports are stored in sub-directories which are named by category.
>State:
Enumerated) The
current state of the PR. Accepted values are:
open
The PR has been
filed and the responsible person notified.
analyzed
The responsible person has analyzed the problem.
feedback
The problem has
been solved, and the originator has been given a patch or other fix.
closed
Th
ffb
e changes have
been integrated, documented, and tested, and the originator has confirmed
that the solution works.
suspended
Work on the problem
has been postponed.
The initial state of a PR is ‘open’. See States of Problem Reports.
>Responsible:
(Text)
The person responsible for this category.
>Arrival-Date:
(Text)
The time that this PR was received by PRMS . The date is provided automatically
by PRMS .
>Audit-Trail:
(MultiText)
Tracks related electronic mail as well as changes in the ‘>State:’
and ‘>Responsible:’
fields with the sub-fields:
State-Changed-<From>-<To>:
oldstate>-<
newstate
The old and new
‘>State:’
field values.
Responsible-Changed-<From>-<To>:
oldresp>-< newresp
The old and new
‘>Responsible:’ field values.
State-Changed-By: name
Responsible-Changed-By:
name
The name of the maintainer who effected the change.
State-Changed-When: timestamp
Responsible-Changed-When:
timestamp
The time the change was made.
State-Changed-Why: reason...
Responsible-Changed-Why:
reason...
The reason for the change.
The ‘>Audit-Trail:’ field also contains any mail messages received by PRMS related to this PR, in the order in which the messages were received.
>Unformatted:
(MultiText)
Any random text found outside the fields in the original Problem Report.