1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
|
The @code{send-pr} program is installed in the directory
@code{@value{ROOTDIR}/bin}.
@need 1100
Before using @code{send-pr} for the first time, you need to install your
customer support ID into the program, by typing the command:
@smallexample
@b{shell%} install-sid @i{customerID}
@end smallexample
@noindent replacing @i{customerID} with your customer ID, which your
sales representative will supply.
The @code{send-pr} program enters the problem report into our Problem
Report Management System (PRMS), which automatically assigns it to the
engineer best able to help you with problems in the assigned category.
The engineer will work with you via email, telephone, or both, and all
email related to this Problem Report will be tracked by PRMS for future
reference. If the engineer does not reply to you after a certain time,
a reminder is automatically generated. If you need to talk to someone
else in our organization about the problem (@i{e.g.}, if the engineer
gets hit by a truck), we can find out what the current state is through
the PR number. @value{COMPANY} uses PRMS for almost all of the real
problems we handle.
The @code{send-pr} program will try to intelligently fill in as many
fields as it can. You need to choose the @dfn{category}, @dfn{class},
@dfn{severity}, and @dfn{priority} of the problem, as well as giving us
as much information as you can about its exact nature.
@need 1000
The PR @b{category} will be one of:
@smallexample
@group
kerberos kerbnet doc help-request
info-request install query-pr id-request
send-pr
@end group
@end smallexample
In general, if specific knowledge about Kerberos is requried to answer a
PR, use the @i{kerberos} or @i{doc} categories. The @i{install}
category is for problems retrieving the code off the media (@i{e.g.},
the data on a tape seems to be corrupted.) Questions about the
installation procedures described in this document would fall under the
category @i{kerberos}. The @i{help-request} and @i{info-request}
categories are for general questions about your contract, or other
issues not necessarily related to @value{PRODUCT}. Use @i{query-pr} to
receive a current copy of your Problem Report, @i{id-request} if you
need a customer ID, and @i{send-pr} if you're having trouble using
send-pr. If your question is related to @value{PRODUCT} and you're not
sure what the most appropriate category should be, use @i{kerberos}.
The engineer can change the category if necessary.
The @b{class} can be @dfn{sw-bug}, @dfn{doc-bug}, @dfn{change-request},
or @dfn{support}. The first two are exactly as their names imply. The
@i{change-request} class is to inform us of changes, such as new email
addresses or new contact information. The @i{support} class is intended
for general questions about using the @value{PRODUCT} clients or
libraries.
The @b{severity} of the problem indicates the problem's impact on the
usability of the @value{PRODUCT} software package. If a problem is
@dfn{critical}, that means the product, component or concept is
completely non-operational, or some essential functionality is missing,
and no workaround is known. A @dfn{serious} problem is one in which the
product, component or concept is not working properly or significant
functionality is missing. Problems that would otherwise be considered
@i{critical} are rated @i{serious} when a workaround is known. A
@dfn{non-critical} problem is one that is indeed a problem, but one that
is having a minimal affect on your ability to use @value{PRODUCT}.
@i{E.g.}, 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 severity is @i{serious}.
The @b{priority} indicates how urgent this particular problem is in
relation to your work. Note that low priority does not imply low
importance. @value{COMPANY} considers all problems important, and
encourages its customers to be realistic about priority ratings. A
priority of @dfn{high} means a solution is needed as soon as possible.
A priority of @dfn{medium} means the problem should be solved no later
than the next release. A priority of @dfn{low} means the problem should
be solved in a future release, but it is not important to your work how
soon this happens. The default priority is @i{medium}.
Note that a given severity does not necessarily imply a given priority.
For example, a non-critical problem might still have a high priority if
you are faced with a hard deadline. Conversely, a serious problem might
have a low priority if the feature it is disabling is one that you do
not need.
The @b{release} is as labeled on the software that was shipped.
@i{e.g.}, @code{kerbnet-@value{RELEASE}}. It is important that you tell
us which release you are using, and whether or not you have made any
private changes.
Bug reports that include proposed fixes are especially welcome. If you
include proposed fixes, please send them using either context diffs
(@samp{diff -c}) or unified diffs (@samp{diff -u}).
@iftex
@vfill
@end iftex
@page
A sample filled-out form from a company named ``Toasters, Inc.'' might
look like this:
@smallexample
@group
To: bugs@@cygnus.com
Subject: "KDC reply did not match expectations" error
From: joe.smith@@toasters.com
Reply-To: joe.smith@@toasters.com
X-send-pr-version: 3.97-96q1
>Submitter-Id: toastersinc
>Confidential: yes
>Originator: Joe Smith (+1 415 903 1400)
>Organization:
-----
Joe Smith joe.smith@@toasters.com
Toasters, Inc.
``The best UI in the world''
>Synopsis: "KDC reply did not match expectations" error message
>Severity: non-critical
>Priority: low
>Category: kerberos
>Class: sw-bug
>Release: kerbnet-1.0
>Environment:
NetBSD viola 1.1 NetBSD 1.1 (ATHENAADP) #0: Tue May 21 00:31:42 EDT 1996
i386
System: Intel P166
Architecture: NetBSD
>Description:
<description of problem goes here>
Getting "KDC reply did not match expectations" message. This
does not seem to be affecting anything else.
>How-To-Repeat:
<A code sample is worth a thousand words.>
<If the Problem Report is marked ``Confidential: yes'',>
<it will not be available to anyone but our engineers,>
<please contact us if you are concerned about sensitive source>
<code.>
It happens when I type kinit.
>Fix:
<If you have already found a correct way to stop this problem,>
<please let us know!>
None. Sorry.
@end group
@end smallexample
@iftex
@vfill
@end iftex
@page
If the @code{send-pr} program does not work for you, you can use the
following template instead:
@smallexample
@group
To: bugs@@cygnus.com
Subject:
From:
Reply-To:
X-send-pr-version: none (typed manually)
>Submitter-Id:
>Originator:
>Organization:
<organization of PR author (multiple lines)>
>Confidential: <[ yes | no ] (one line)>
>Synopsis: <synopsis of the problem (one line)>
>Severity: <[ non-critical | serious | critical ] (one line)>
>Priority: <[ low | medium | high ] (one line)>
>Category: <name of the product (one line)>
>Class: <[ sw-bug | doc-bug | change-request | support ] (one line)>
>Release: cns-9?q?
>Environment:
<machine, os, target, libraries (multiple lines)>
System:
Architecture:
>Description:
<precise description of the problem (multiple lines)>
>How-To-Repeat:
<code/input/activities to reproduce the problem (multiple lines)>
>Fix:
<how to correct or work around the problem, if known (multiple lines)>
@end group
@end smallexample
|
