ICESS Systems Group Change Control Policy

The ICESS Systems Group observes the following policy when making configuration changes (including, but not limited to, making changes to a /local file system) that have a global impact on the user-visible look and feel of the computing environment.

This policy is not intended to apply to operational changes needed to keep the working stuff working, for example, restarting print queues or rebooting hung systems; rather, it is intended to apply to planned changes in configurations that may or will change the observed function of some properly functioning part of the environment from a users' point of view. For example, this policy applies when updating a shared software package or upgrading the operating system on a globally-used compute server.

  1. Notification
  2. A message describing the what, when, and why of a change will be sent to

    The message will be sent at least 24 hours before the change is made unless the change is urgent. The definition of urgent is left to the judgement of the person making the change.

    If less than 24 hours of notice is given, the notification will state the reason why.

  3. Testing
  4. If possible, a change will be tested before being installed so that there is a reasonable expectation of the change working at least as well or better than what was previously being used. New installations of functionality that require explicit action on the part of the user to reference (e.g. changes to a path variable in a .cshrc) may be tested in situ.

  5. Checkpointing
  6. A copy of the previous version of whatever is being changed will always be saved so that the change can be backed out if needed. The RCS commands "co -l" and "ci -u" will be used to checkpoint changes involving individual configuration files.

    Large directory hierarchies can be checkpointed by appending a version number to the name of the hierarchy root directory; for example, checkpoint a IDL installation by renaming /local/idl to /local/idl-3.6.1.

    If a new software package will be used by only a few people, install it in a new path that requires explicit action on the part of the user to reference.

    The nightly backups will not be relied upon for checkpointing unless the installer has verified that all files of the versions needed are visible in the Networker indexes.

Please send any comments or suggestions regarding this policy to:

Last update, Wed Dec 2 15:05:38 PST 1998, Ed Mehlschau <>.