This volume is for AFS records of machine configurations.  The
volumes will be created for individual machines as appropriate.
The layout and procedures for each machine configuration volume
will be determined by the maintainers of that machine.

Below is a mail message I (ghudson@mit.edu) sent out upon creating
this volume about migrating from the old (dis-)organization to
this new one.

---

To avoid confusion: the words "machine" and "service" below are
literal words, *not* syntactic keywords.  When I am talking about
/afs/sipb/machine, for instance, I am not talking about
/afs/sipb/{ronald-ann,charon,milquetoast,etc.}.  (The actual
directories should be
/afs/sipb/machine/{ronald-ann,charon,milquetoast,etc.}.)

My plan is this:

	* All machine configurations should be moved to machine.*
volumes in /afs/sipb/machine, which can be created and assigned quotas
through lazy allocation.

	* All service volumes should be moved to service.* volumes in
/afs/sipb/service, which can also be created and assigned quotas
through lazy allocation.  Service volumes should contain sources,
binaries, documentation, and other material related to SIPB network
services.  For instance, I'll move project.rtfm to service.rtfm soon.

	* Overlap between files in the service volumes and
machine-specific volumes should be handled in whatever fashion the
machine and service maintainers believe is appropriate.  Likewise,
machine configurations should be managed according to how the
maintainers want to do it.  However, I strongly suggest that people
avoid making references to /afs/sipb/machine/* from outside, instead
making references to /afs/sipb/service/*.

	* Currently in service, we have a directory 'partitions',
which can probably stay there, and a bunch of directories @sys which
contain binaries to use for that cell.  I don't know if anyone uses
those binaries; they can probably move somewhere else, although I'm
not sure where is best.

I said "SIPB network services" above when talking about what should go
in /afs/sipb/service.  It is possible that we should expand this to
include non-network services such as the SIPB locker, the outland
locker, the linux locker, etc..  When we discussed this over zephyr,
though, it became rapidly clear that the distinctions between
"project", "service", and "software" are extremely unclear, and we
should be very careful about making arbitrary decisions in that
regard.  So, for now, I view /afs/sipb/service as only for
'partitions' and the network services.

(The answer to the above question also helps determine where
/afs/sipb/service/@sys moves to.)