#pragma ident   "@(#)rtitool.general_help 1.27     96/08/06 SMI"

#  It is a general help file. All help information that is related to 
#  Help->General Help should be stored in this file.
#  Here are two special symbols:   @  and  #
#
#  The pound symbol '#' placed at the beginning of string means that this
#  string is considered a local comment. As such, it will not appear in the
#  Help window accessible in rtitool.
#
#  The '@' placed in first position of the string means that this string
#  will be considered as an item of General Help menu and everything below
#  this string up to next '@' symbol  or  end of file would be shown when
#  user chose an appropriate menu item from General Help Menu.
#
#
@Rtitool overview
There are two types of RTI's: implementor and patch.  Implementor
RTI's are request to integrate source changes into the current 
release(s) under development. Patch RTI's are requests to generate
patches for FCS'ed releases; they are generally initiated by
customer escalations.

Rtitool is an ON utility which allows ON developers to:

	- Submit implementor and patch RTIs to the ON CRT 
	  (Change Review Team) for review and approval.

	- Query the state of a specific RTI.

Rtitool also allows ON CRT members/evaluators to:

	- Review and respond to implementor and patch RTIs on 
	  their queue.

Rtitool is effectively a front-end to the rtiroute database
of implementor and patch RTIs on wizard.

Using rtitool to submit RTIs has the following 
key advantages over the ASCII RTI templates: 

	- Fetches P/S and Synopsis info from Bugtraq, 
	  given a bugid.
	- Verifies that a bugid is evaluated before sending
	  RTI's.
	- Verifies that required fields are completed before
	  sending RTI's.

Other advantages are:

	- Rtitool keeps track of the appropriate aliases to
	  which RTI's should be sent.
	- Optional automated logging of all RTI's sent.

Rtitool is organized into two main panels.  The top panel is the 
Command panel and allows you to control the functions of the tool.
The lower panel contains the RTI templates. There are three 
templates: implementor, patch, and evaluator.  The implementor
and patch templates are used to submit RTI's and the evaluator
template is used by the ON CRT members to evaluate implementor
and patch RTI's.

The Props window lets you set defaults for the fields in the
templates, so when creating a new RTI it will be initialized with 
these defaults.  You also have the option of setting up an outgoing
log which will record all of the RTI's submitted with Rtitool
into a mailbox file.  

@Bugtraq interface
Rtitool does not require an account on Bugtraq+, however one is
highly recommended, if you are submitting RTI's which may 
require you to update bugs in Bugtraq+, to meet the requirements 
of RTI submission.

You may request a Bugtraq+ account via the Software Service
button on the Service Desk tool (execute 'service' at the command 
line).

There is a web page for Bugtraq+ at http://ssir.Eng/Bugweb/bugtraq+,
with information on support and documentation.

@Risk & Impact Codes
======================
Release 2.1 and later:
======================

Bugid   P S Impact Risk Synopsis
------- - - ------ ---- -----------------------

Where Impact is composed a impact,type(s)

Impact:
    0 = NONE
    1 = VERY LOW
    2 = LOW
    3 = MEDIUM
    4 = HIGH
    5 = VERY HIGH

Type of impact:
    a = API changes
    h = header file changes
    p = packaging/namespace changes
    d = documentation/man page changes
    o = other changes

Risk:
    1 = VERY LOW. Obvious impact.
    2 = LOW. Obvious impact.  Little chance of unexpected side effects.
    3 = MEDIUM. Change is well understood but significant.  Possible side
        effects.
    4 = HIGH. Change is in a critical area.  Probable side effects.
    5 = VERY HIGH. Change is large.  Change is in a critical area.  Not
        well understood.


=======================
Release 2.0 and before:
=======================

Bugid   P S ID Reason    Risk Synopsis
------- - - -- --------- ---- -----------------------

ID (Impact on Documentation):
    0 = NONE
    1 = MINOR changes (args, a few words)
    2 = MEDIUM, additional verbiage up to and including a paragraph or two
    3 = MAJOR, additional pages and/or rewrites of sections, changes to
        more than a single document

Reason:
    - = "Uninteresting" to CRT (e.g. trivial bug fix in very isolated code)
    1 = High risk
    2 = Marginal risk/benefit ratio (e.g. high risk/no gain)
    3 = Intergroup dependencies (any)
    4 = New functionality (all RFE's)
    5 = Any namespace or packaging changes (includes file permissions,
        ownerships, path, name, and containing package)
    6 = Any semantic header file changes associated with bug fix
    7 = Resubmission (missed window or appealing decision)
    8 = API change e.g. a new API, or a change to an existing API that may
        affect binary compatibility.
    9 = Other reasons.  Please explain in "Comments" section of RTI.

Risk:
    1 = Very Low.  One or two line change with obvious consequences.  Only
        risk is in putback.  (Few changes really fit this category.)
    2 = Low.  Changes have only obvious impact.  Little chance of unexpected
        side effects.
    3 = Medium.  Change is well understood but relatively large.  Errors are
        possible in new code as well as in interactions with other parts of
        system.
    4 = High.  Change is large or in very heavily used core part of system
        (e.g. changes to vm behavior)
    5 = Very High.  Change is large and in critical area, where interactions
        with all parts of system are not well understood.

@Known Problems

	1) Rtitool version 2.7 and later is not supported on the 
	   PPC platform, due to lack of Sybase libraries for PPC, 
	   required for new bugtraq+ support.

	   Workaround: Execute rtitool on a sparc or x86 system,
	   displaying it to the PPC.
	   Before executing rtitool on the sparc/x86 system,
	   do the following.

	   On your ppc system:
	   % xhost +

	   On your sparc/x86 system:
	     in sh or ksh,
	   % DISPLAY=<ppc hostname>:0; export DISPLAY
	     or in csh,
           % setenv DISPLAY <ppc hostname>:0

	2) Entering > 10,000 characters in a text window, such
	   as "Deliverables", "Comments", or "Description",
	   will truncate the value at 10,000 characters.
	   
	   Workaround: Enter the value by submitting it via an
	   e-mail to on-crt@lizard.Eng.  The contents of the 
	   message should be as follows (example below shows 
	   updating the field "Deliverable Source Files"; 
	   replace this with the appropriate field name):

	   Action: update
	   RTI #: <your RTI #>

	   Deliverable Source Files:

	   <text to go into this field appears here>

Please report problems to rtitool-comments@lizard.Eng.

@Related Docs
For further information regarding the integration process and
other related topics, see the ON documentation roadmap, which 
can be found at:

	/shared/ON/general_docs/roadmap.txt
	(wizard.Eng:/export/misc/general_docs/roadmap.txt)

For more information on patches, see

	/shared/ON/patch_docs/common/README_patch.txt
	(wizard.Eng:/export/misc/patch_docs/common/README_patch.txt)

@Revision Notes
Revision 2.7 - 8/96

	New Features/Enhancements

	1) Support for bugtraq+ database.

	2) Now checks for an empty "Root Cause" bugtraq field 
	   for patch RTI's, if a "patch regression" is indicated 
	   in the Patch Request Origin field.  Reminds user that
	   "Root Cause" should be "from another bug fix".

	Bug Fix

	1) Now checks the 'Releases to Patch' field for missing
	   architectures, when updating or resubmitting a patch RTI, 
	   as well as when creating a patch RTI.

Revision 2.6 - 4/15/96

	New Features/Enhancements

	1) Redesign of "Patch Request Origin" field in patch 
	   template, to obtain more accurate information for 
	   patch reporting purposes.
	   
	2) Removed the "appeal" action from both the implementor
	   and patch templates.  "Appeal" was infrequently used,
	   and did exactly the same as a "resubmit" action.

	3) "Justification" button on patch template is now 
	   "Origin/Justification", to more accurately reflect
	   the fields in the corresponding popup.

	4) "Spot Help" reminder message at bottom of each template.

	Bug Fixes

	1) Rtitool will now display an error if you submit RTI's
	   against "accepted" bugs.

	2) Resubmit will no longer cause the unecessary creation 
	   of a new "Last_Evaluator" line in the RTI header of 
	   patch RTI's.
	   
	3) "Show" now displays consistently for Action "create",
           for both implementor and patch RTI's.

	4) Description field in header of patch RTI file is now
	   consistent when user updates the release field.


Revision 2.5.1 - (rtiroute only) - 1/24/96

	1) Aliases on local machines entered on the "Patch Requestors" 
	   or "Code Reviewers" fields now are used correctly, retaining 
	   the machine name in the address.

	2) Use local version of perl on lizard, rather than relying
	  on remote perl on /usr/dist.

	3) Add release name(s) in subject header of implementor RTI
	  acceptance message.

	4) Fixed bug which erroneously processes mail messages as
	   RTI actions, when the mail includes a message containing 
	   the "Action:" keyword (happens when users send mail to 
	   on-crt@lizard or on-crt@benet, including mail received on 
	   an RTI).  Now the mail is correctly forwarded to the 
	   crt-all@lizard alias.  Keys off the bracketing lines:
	   ----- Begin Included Message -----	
	   and
	   ----- End Included Message -----

Revision 2.5 - 11/06/95
	New Features/Enhancements

	1) Implementor and evaluator templates now allow selection 
	   of on297.

	2) When accepting an RTI under the evaluator template,
	   select a Release to Integrate Into, rather than
	   a Phase to integrate by.

Revision 2.4.3 - 10/16/95


        New Features/Enhancements

        1) PPC now officially supported along with X86 and Sparc.

        Bugs Fixed:

        1) Able to query bugids from Bugtraq database through 
           query button (on sparc and x86 systems only).  
	   This capability broke a few months
           ago due to a change in Bugtraq database.

Revision 2.4.2 - 3/95


        New Features/Enhancements

        1) Group all bugtraq error checking to be done at one time.

        Bugs Fixed:

        1) "Undefined name" errors when bringing up rtitool.  Rtitool will not
           come up.  Looks like memory mgmt problem.

        2) Rtitool v2.4.1 will core dump if you try to reset the CRT advocate
           in the implementor RTI properties sheet.

        3) Security field should be mandatory in patch rti.

        4) Clarification of error message "Suggested Fix is undefined in
           bugtraq" and "jjv is not a valid email address".

        5) The Code Reviewed By: field is not cleared when you select either
           form of the Reset button in the implementor rti template: Clear
           all fields and load default values, or Clear all fields.

        6) "Code Reviewed by" field  in the Implementor RTI may be blank
            without rtitool complaining.

        7) On the Query popup window, the header field is not updated
           properly.

        8) Correct spot help errors.
   
        9) Core dump when inputting 10 digit opinion numbers in
           Arc popup.

       10) Core dump in evaluator template when doing forwarding.

Revision 2.4.1 -  11/14/94
       

        New Features/Enhancements

        1) Backed out approval by release.  Previous policy of approval by phase
           reinstated.
    
        Bugs Fixed:
 
        1)  Reassign/Hold requiring wrong fields in evaluator's template.
        2)  Erroneous error with bugtraq checks in patch template when bugtraq
            was inaccessible.

Revision 2.4 - 11/09/94


	New Features/Enhancements

	1)  Query of RTI extended to match implementor, patch, and archived
	    patch RTIs with the same RTI number a single query.
	2)  Additional bugtraq checks added.  Rtitool now requires Responsible
	    Manager, Responsible Engineer, and Suggested Fix to be defined in
	    bugtraq for all bugids before a RTI can be submitted.
	3)  "Code Reviewed By" field added to the implementor RTI.
	4)  "Test Results" field added to patch RTI.
	5)  "Patch Request Origin" field added to patch RTI
	6)  New default choices for "Patch Justification".
	7)  Bugtraq checks (state, RM, RE, and Suggested Fix) are redone when
	    an evaluator attempts to accept a RTI.
	8)  Changed approval implementor RTIs for a phase to a release.
	9)  Removed approval of patch RTIs for patch/point patch.
	10) Cancel action added to evaluator's window.

	Bugs Fixed:

	1)  Now works with different font families/sizes.
	2)  Ensure that the bugid(s) are followed by a blank line (required
	    by rtiroute).

Revision 2.3 - 07/25/94

	New Features/Enhancements

	1)  List of ARCS now configurable via the config file.  HPARC added
	     to the list.
	2)  Advocates may now forward CRT assignments for other advocates.
	3)  The evaluator's forward popup now contains a list of all the
	     currently installed forwards.
	4)  CRT approval of patch RTI's.
	5)  For patch RTI's, Explicit selection of release(s)/architecture(s)
	     to patch.

	Bugs Fixed:

	1)  Fixed the code which corrupted the PATH environment variable.
	     This caused some items in the Textsw extras menu to fail because
	     the programs to perform the function could not be found.
	2)  In Patch template, only show the "Security Bug?" field when a
	     choice has been selected.
	3)  "checkbodes" spelling error fixed in Patch justification popup.


Revision 2.2 - 05/16/94

	New Features/Enhancements:

	1)  Button marks added for popups that have been filled in (ala
	     rtitool1.2).
	2)  Patch RTI template.
	3)  Resubmit action added to Implementor template.
	4)  Access rtiroute databases through /shared/ON/rtiroute_db
	    automount point.

	Bugs Fixed:

	1)  Removed references to codes, ID, and Reason in bugids popup.
	2)  Removing the wrong RTI from the evaluator list when a mail
	    message is sent.
	3)  Displaying RTI's in the evaluator list which have been reassigned.

Revision 2.1 - 04/18/94

	New Features/Enhancements:

	1)  A default CRT advocate can be set via props.
	2)  Print option added to "File" menu.
	3)  Default save to directory same as props log directory.
	4)  RTI logging
	5)  Evaluator CRT ID moved from props to main window.
	6)  List all open RTI's (blank CRT id).
	7)  Evaluator RTI list numerically sorted.
	8)  Busy cursor when quering a RTI via a double click in the
	    evaluator list.
	9)  New Risk & Impact codes.
	10) Risk & Impact code/strings controlled by config file.
	11) Reset in ARC Opinions window resets ARC to first choice and
	    Year to the current year.
	12) Forward/unfoward evaluator actions supported.
	13) Return on the RTI# text field in the Query popup initiates
	    the query.
	14) Intel Bugtraq props items removed.
	15) Bugid Codes section added to general help.
	16) RTI number automatically added to the Query list when a message
	    is sent.
	17) Implementor windows reset upon send.
	18) Spot help added.
	19) Default advocate selectable from popup menus.
	20) Implementor flags.

	Bugs Fixed:

	1)  Subject line wrong for cancel action.
	2)  Disappearing popups in CDE.
	3)  Wrong window layout in older versions of XView
	4)  Using fprintf to print bugids text (caused %'s to be expanded).
	5)  Including blank fields in update & appeal actions which caused
	    loss of information in the RTI header.

Revision 2.0 - 03/01/94

	New features:

	1) Added support for CRT Advocate in the implementor
	   template; removed support for Sponsor.
	2) Added query support to query both the rtiroute 
	   database of implementor RTIs and bugtraq.
	3) Added support for multiple ARC opinion numbers.
	4) Added an evaluator template for use by CRT members.
	5) Reimplemented utility to improve supportability.
	6) Reworked "look and feel" of GUI to improve 
	   extensibility in case we choose to add patch RTI
	   or gatekeeper RTI support in the future.

	Bug fixes/RFE's:

	1)  CRT advocate expertise string now displayed in popup menu
	    exactly as it appears in the file.
	2)  CRT advocate menu button now activated/inactivated to match
	    advocate type-in.
	3)  CRT advocate menu is now pinable.
	4)  Changed the "Request Submitted" alert to a message in the
	    frame footer.
	5)  Removed on1093 as a target release.  Added on495.
	6)  Reset in Implementor template now clears CRT advocate field.
	7)  Help windows no longers appears at the top, left-hand corner
	    of the screen each time it is selected.
	8)  Fixed subframe titles and buttons/menu items which invoked
	    popup windows but was missing "...".
	9)  Fixed bug where evaluator panel was sometimes not correctly
	    resizing after switching between templates.
	10) Advocate menu now sorted by last names.
	11) Increased the stored length from 50 to 256 on the Feedback
	    window type-ins.
	12) Added Cc: line to Feedback window.
	13) Fixed seg fault if config file is not found.
	14) Use unique temp file names.
	15) Query facility reworked:
		i)	Removed "Get Selection" button
		ii)	Fix file descriptor and window leaks.
		iii)	List now sorted.
		iv)	More informative error notices.
	16) Double click in evaluator RTI list now uses query window.
	17) Query & evaluator RTI list inactivated when no RTI databases
	    are defined in the config file.
	18) Submit button changed to Send.
	19) ARC approval date removed.
	20) Changed Explain to Comments in evaluator template.
	21) New set of integration phases.
	22) Fix send and query bugs introduced in beta4.
	23) Changed config file names to match version 1.0.

Revision 1.2 - 10/13/93

	Bug fixes/RFE's:

	1) Added support for new bugtraq database queries
	2) Removed access to the gatekeeper rti templates from within
	   rtitool.  Gatekeeper RTI's are once again submitted
	   from a text template and *not* from within Rtitool.
	3) Changed "codes" button to "risk&impact" button in the
	   one liner pop-up.
	4) Changed several of the "risk&impact" codes on the 
	   "risk&impact" pop-up.  (per request from Tim Marsland).
	5) Removed NIS check for the sponsorid field.  This can 
	   be a mail alias that is not NIS-checkable 
	   (ie: paul.richards@central).

Revision 1.1 - 1/20/93

	New features:

	1) List of releases, gates, aliases, and actions are
	   read in from a global properties file so they can
	   be modified at any time without rebuilding the tool.
	   Reported by Claire Giordano.
	2) Added "create bugid list" button menu to Deliverable
	   description window in Gatekeeper template.  Reported
	   by Claire Giordano.

	Bug fixes/RFE's:

	1) The "PSARC opinion number" field was bogus in that it
           didn't allow for opinions from other ARC's, and it
	   didn't include the year of the opinion.  So field label
	   was changed to "ARC opinion number", and ARC/year field
	   was added.  Reported by Joe Kowalski and Bill Shannon.
	2) "Gate for integration" text field changed to read-only.
	   Reported by Craig Mohrman.
	3) Fixed problem with bugtraq button where if it was
	   pressed twice in succession using a bugid with a
	   multiline synopsis, the second line was duplicated.
	   Reported by David Kahn, Jim Moore and Claire Giordano.
	4) A notice window will alert the user to unevaluated
	   bugs, in addition to the message in the error log.
	   Reported by Tim Marsland.
	5) In Gatekeeper template, an unevaluated bugid is listed
	   in the error log as a warning, not an error.  Reported
	   by Claire Giordano.
	6) Reply button is made inactive if "Load from Mail file"
	   window is empty.  Reported by Craig Mohrman.
	7) In Reply message, changed "Action: reassign" to
	   "Action: reassign to |> login <|".  Reported by Craig
	   Mohrman. 
	8) Reply window resizes correctly.  Reported by John
	   Spiller.
	9) Corrected initial default for maillog setting when
	   starting Rtitool without setting the properties.
	   Reported by David Kahn.
       10) Improved tool real estate.  Reported by Tim Marsland.
       11) Symlinks followed in searching for help files.
	   Reported by Claire Giordano.
       12) In Gatekeeper template, shell errors are captured
	   correctly when executing the "Do putback" command in
	   "create file list" menu, and "Run command" in "create
	   packaging list" menu.

	Documentation changes:

	1) Documented rtitool/mailtool interaction problem.  
	   Reported by Brent Callaghan.
	2) Added definition of "above the line" to spot help file.
	   Reported by Len Brown.
	3) A man page is now available.  Reported by Claire
	   Giordano.

@How to File Bugs
You can submit bugs, comments or suggestions regarding Rtitool 
via an option on the Help menu called Send feedback.  

The Send feedback menu button puts you in a popup window (similar 
to a mailtool compose window) which will automatically send your 
feedback to:

	rtitool-comments@lizard.Eng.

@About rtiroute

				Rtiroute 2.4

Introduction
===========

Rtiroute is a mail filter program which maintains a database of Requests
To Integrate (RTI's). There are two types of RTI's: implementor and patch.
Implementor RTI's are request to integrate source changes into the current 
release(s) under development. Patch RTI's are requests to generate
patches for FCS'ed releases; they are generally initiated by
customer escalations.

Email messages to create, update, resubmit, cancel, and accept RTI's are
sent to an address associated with the rtirouter.  The rtiroute software
stores these messages in a queue directory and processes them serially
in the order they were receieved.

The mail messages accepted by rtiroute are free format consisting of
keywords and values.  Rtiroute only cares about the fields that it
is interested in and ignores everything else.  The format of messages
to perform the supported actions are listed below.  The GUI program,
rtitool, provides an easy mechanism to compose the mail messages.

To allow for an easy reply to mail messages generated by rtiroute, the
rtiroute mail address is also used for the CRT mailing list.  The keyword
^Action: is used to determine if the message is a directive to rtiroute
or a message for the CRT.  This simple mechanism can lead to CRT messages
being interpreted as rtiroute messages.  If you reply to a rtiroute mail
message and include the original text, be sure to use an indent character
or bracket the original text with

----- Begin Included Message -----

----- End Included Message -----

so the Action keyword will not be interpreted.

Implementor RTI's are accepted for integration into a release 
and Patch RTI's are accepted for specified release(s), by members
of the CRT.  A list of CRT advocates (evaluators) is kept in the
advocates.config file.  Only these people may use the evaluator actions.

Rtiroute keeps a complete history of mail messages associated with an
RTI in the RTI file in reverse chronological order.

Actions
=======

Create:

Create a new RTI for a bug or a group of bugs.  RTI's are assigned the
same number as the bugid.  If it is associated with a group of bugs, the
first bugid is used.  The message must include the email address of CRT
advocate to evaluate this RTI.  The advocate will be sent an evaluate
mail message. 

Resubmit:

Resubmits an RTI that needs to be reconsidered, e.g. the RTI was
cancelled by the evaluator.  Another example might be that the 
RTI was approved for on596, the on596 gate has closed, and the RTI 
wasn't integrated.  The submitter would resubmit for on297, and the
RTI will be reopened for evaluation.  If no advocate is specified, 
the orginal is used.  The advocate will be sent a re-evaluate message.  

Update:

Update the information associated with the RTI.  The advocate will be
sent an update mail message.

Cancel:

Cancel a RTI.  The advocate will be sent a cancel message.

*** The following actions are for evaluators only. ***

Accept:

Accept an RTI for a release or accept a patch RTI for specified 
release(s).  The originator of the RTI will be sent an accept
mail message.

Hold:

Place a RTI on hold.  The originator of the RTI will be sent a hold mail
message.

Reassign:

Reassign a RTI to a new CRT advocate.  The original advocate will be sent
a drop evaluation message and the new advocate an evaluate message.

Forward:

Forward a CRT advocate's assignments to another advocate.  The forward
advocate will be sent a message informing them who is forwarding their
assignments to them.

Noforward:

Remove a mail forward.  The advocate that was receiving your forwarded
assignments will be sent a message telling them the forward has been
removed.

States
======

Open:

The initial state of a newly created RTI.

Accept:

The final state of a RTI which has been accepted.  For implementor
RTI's, the RTI has been accepted for a release.  For
patch RTI's, the RTI has been accepted for specified release(s). 

Hold:

A RTI is put on hold when the evaluator does not have time to evaluate the
RTI or is awaiting more information from the implementor.

Expird:

A RTI enters the expird state when it has not been accepted or put on hold
within the required time period.

Cancel:

An RTI has been cancelled.


State Transition Diagram
========================

In the diagram, each action that causes a transition to a new state, is
followed by a letter in parentheses.  This indicates whom originates
the action:

    (I) := Implementor
    (E) := Evaluator
    (R) := Rtiroute


                                              cancel (I)
                                           +---------->[1]
                                           |
				      +--------+
		         expire (R)   |        |
		 +------------------->| EXPIRD |------------------+
                 |                    |        |   accept (E)	  |
                 |                    +--------+		  |
	         |       resubmit (I)    |  |                     |
		 |  +--------------------+  |                     |
                 |  v    reassign (E)       | hold (E)            v
              +--------+	            |                 +--------+
              |        | accept (E)         |                 |        |
  ----------->|  OPEN  |--------------------)---------------->| ACCEPT |
  create (I)  |        |		    |		      |        |
              +--------+		    |		      +--------+
	        | | ^    resubmit (I)       |                     ^
	        | | |--------------------+  |                     |
		| | |    reassign (E)    |  v                     |
	        | | |                 +--------+                  |
	        | | |    hold (E)     |        |   accept (E)	  |
	        | +-)---------------->|  HOLD  |------------------+
		|   |                 |        |
		|   |    resubmit (I) +--------+
	        |   +-----------+         |
                |               |         | cancel (I)
		|	    +--------+    |
		| cancel(I) |        |    |
		+---------->| CANCEL |<--------[1]
			    |        |
			    +--------+



Message Formats For Implementor RTI's
=====================================

Create Action:
--------------

	Advocate: <advocate>
	Action: create
        Code Reviewed By: <peer who reviewed code>
	Target release: <release>
	
	Bugid   P S Impact    Risk Synopsis
	------- - - --------- ---- -----------------------
	<bugid> ...

	======================
	ARC Opinion Number(s):
	======================
	PSARC/1994/100


	=========
	Comments:
	=========
	This is a comment.

Advocate and the peer who reviewed the code must be a valid email
address relative to a Sun domain (<user>@<domain>).  The special
keywords Default or default may be used to assign the RTI to the
default advocate.

ARC and comments are optional.

Resubmit Action:
---------------

       Action: resubmit
       RTI#: NNNNNNN

All other fields valid for the "create" action are optional.  If an
advocate is not specified, the original evaluator is used.

Update Action:
--------------

	Action: update
	RTI#: NNNNNNN

All other fields valid for the "create" action are optional except advocate
which is ignored. 

Cancel Action:
--------------

	Action: cancel
	RTI#: NNNNNNN

Accept Action:  (Evaluator only)
--------------

	Action: accept
	RTI#: NNNNNNN
	Integrate into: <release>

The "Integrate into:" field is only applicable for implementor RTI's.

Hold Action:  (Evaluator only)
-----------

	Action: hold
	RTI#: NNNNNNN
        Comments:

The comments section is mandatory to explain the reason for this action.

Reassign Action: (Evaluator only)
---------------

	Action: reassign to <advocate>
	RTI#: NNNNNNN

See the note in create action on the format of <advocate>.

Forward Action:  (Evaluator only)
--------------

	Action: forward to <advocate>

The From address of the mail message is used to determine the advocate to
forward.

See the note in create action on the format of <advocate>.

Noforward Action:  (Evaluator only)
----------------

	Action: noforward

The From address of the mail message is used to determine the advocate to
remove forwarding.


Message Formats for Patch RTI's
===============================

The above messages are also valid for patch RTI's.  However, there are
additional fields when creating a patch RTI:

Patchid
Cte Escalation #
Patch Requestor
Security Bug
Commit to Integrate in
Releases
Description
Deliverables
Impact
Patch Request Origin
Patch Request Origin--Additional Info
Justification
Point Patch 
Test Results
