.nr Hu 1
.SK
.HU "APPENDIX G"
.SP 2P
.ce
.B
\s16\*(Np Update Policy\s0
.R
.SP 2P
\f3G.1 Code Changes\fP
.P
Procedures for handling user selected code changes are:
.AL 4
.AL 2
.LI
Send suggested code changes via e-mail to \*(Em.
When a final disposition is determined a response will be
provided to the submitter.
Code changes must conform to \*(Fp and must correct a \*(Np
deficiency in existing code.
.LI
If deemed appropriate by the \*(Nl review committee,
suggested code changes will be integrated into the \*(Np and
evaluated in-house on all \*(Nl systems used for \*(Fp testing.
.LI
When testing is completed, the changes will be
queued for eventual distribution as a BETA Patch for the Official \*(Np
to \*(Np owners who are e-mail accessible.
.LE
.LE
.P
\f3G.2 Patches\fP
.P
.AL 4
.AL 2
.LI
Updates are normally distributed as a shell script file which
utilize the \f(CW\fP utility to automatically update source modules.
The update will also generate a text file which specifies the
changes performed.
When appropriate, an update will be distributed as a complete
redistribution of the \*(Np.
.LI
All updates distributed to APTLs will be logged.
Each APTL on receipt of an update must acknowledge receipt.
\*(Nl will maintain records on notification and acknowledgement.
.LI
\*(Nl will provide two types of updates, the BETA Patch
and the FIXES Patch.
The BETA Patch is configured to be installed on the latest
Official \*(Np.
The BETA Patch represents fixes that have been generated and tested by \*(Nl.
These fixes are made available,
to the testing community, for final checkout before being integrated
into a FIXES Patch.
.P
BETA Patches are short lived, with a target life of two to eight weeks.
If no negative comments have been received, the current BETA Patch
will be integrated into an updated FIXES Patch or a complete redistribution.
.LI
All BETA Patches and FIXES Patches generate an update that
records the date the Patch was released.
.LI
At most, one BETA Patch will exist at any time.
An updated BETA Patch, FIXES Patch, or \*(Np redistribution
terminates the prior BETA Patch
(i.e., if the date associated with a FIXES Patch is later than the date
associated with a BETA Patch, the BETA Patch no longer applies).
.LI
An updated FIXES Patch, replaces the prior FIXES Patch and
represents an official update of the \*(Np.
The official
date of the updated \*(Np is automatically reported in
the generated test results.
.LE
.LE
.bp
\f3G.3 Installing Patches\fP
.P
Whenever a FIXES Patch is distributed by \*(Nl, the \*(Np
to be used is the combination of the last \*(Np distribution
and the FIXES Patch file.
The procedures for
generating the Official \*(Np are as follows:
.AL 4
.AL 2
.LI
Load the last \*(Np distribution.
The commands provided below perform this procedure on our
implementations but may vary on your implementation.
.nf
.ta 0.5i
	\f(CW tester_login_directory
	cpio -icBdmu[v] <distribution_file\fP
.fi
.LI
After removing any extraneous information added by the e-mail
distribution, execute the FIXES Patch file.
This file requires utility \f(CW\fP to produce the
current Official \*(Np.
A text file will be generated which provides
a description of the changes performed.
.P
When executing the Patch file, save the journal output produced by
\f(CW\fP to ensure that all patches were performed.
In the Bourne shell execute the following command.
.nf
.ta 0.5i
	\f(CW Patch_file 2>p_patch_rslts\fP
.fi
The sources for \f(CW\fP are distributed with the \*(Np.
.P
The revision level of the \*(Np will be updated to
specify the FIXES Patch used.
This revised level is reported in the output reports generated.
.LI
Create the new Official \*(Np.
The commands provided
below perform this procedure on our implementations but may vary
on your implementation.
.nf
.ta 0.5i
	\f(CW NIST-PCTS -print | cpio -omcB > special_file\f1
.fi
.LI
Use the newly created Official \*(Np for all future testing.
.LE
.LE
