If you have problems installing PRODUCT, please use the send-pr program to fill out a Problem Report.

The send-pr program is installed in the directory ROOTDIR/bin.

Before using send-pr for the first time, you need to install your customer support ID into the program, by typing the command:

     shell% install-sid customerID

replacing customerID with your customer ID, which your sales representative will supply.

The 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 (e.g., if the engineer gets hit by a truck), we can find out what the current state is through the PR number.  COMPANY uses PRMS for almost all of the real problems we handle.

The send-pr program will try to intelligently fill in as many fields as it can.  You need to choose the category, class, severity, and priority of the problem, as well as giving us as much information as you can about its exact nature.

The PR category will be one of:

     kerberos        kerbnet         doc             help-request
     info-request    install         query-pr        id-request
     send-pr

In general, if specific knowledge about Kerberos is requried to answer a PR, use the kerberos or doc categories.  The install category is for problems retrieving the code off the media (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 kerberos.  The help-request and info-request categories are for general questions about your contract, or other issues not necessarily related to PRODUCT.  Use query-pr to receive a current copy of your Problem Report, id-request if you need a customer ID, and send-pr if you're having trouble using send-pr.  If your question is related to PRODUCT and you're not sure what the most appropriate category should be, use kerberos. The engineer can change the category if necessary.

The class can be sw-bug, doc-bug, change-request, or support.  The first two are exactly as their names imply.  The change-request class is to inform us of changes, such as new email addresses or new contact information.  The support class is intended for general questions about using the PRODUCT clients or libraries.

The severity of the problem indicates the problem's impact on the usability of the PRODUCT software package.  If a problem is critical, that means the product, component or concept is completely non-operational, or some essential functionality is missing, and no workaround is known.  A 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 critical are rated serious when a workaround is known.  A non-critical problem is one that is indeed a problem, but one that is having a minimal affect on your ability to use PRODUCT. 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 serious.

The priority indicates how urgent this particular problem is in relation to your work.  Note that low priority does not imply low importance.  COMPANY considers all problems important, and encourages its customers to be realistic about priority ratings.  A priority of high means a solution is needed as soon as possible. A priority of medium means the problem should be solved no later than the next release.  A priority of 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 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 release is as labeled on the software that was shipped. e.g., kerbnet-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 (diff -c) or unified diffs (diff -u).

A sample filled-out form from a company named ``Toasters, Inc.'' might look like this:

     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.

If the send-pr program does not work for you, you can use the following template instead:

     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)>