-----------------------------------------------------------------------------
	Standards and Conventions for Shag/OS:
-----------------------------------------------------------------------------

	This includes coding standards, as well as source code control
	standards, and various other standards followed throughout
	the distribution. 

-----------------------------------------------------------------------------
Directories:
	All directories in the source tree will have '.purpose'
	files which contain a short one or two line description of the
	purpose of the directory.  When 'mkheader' is used to update
	the headers on files, the relative path from root of the source
	tree to the file being updated is used to automatically 
	build a list of purposes to put at the top of the file.

-----------------------------------------------------------------------------
Comments:
	These standards are for special types of comments, so that they
	can be easily searched for.

Comments: (old style -- needs to be searched for and eliminated )
	//X//  bugs that need immediate attention
	////X  or code that needs filling in
	//A//  additions that should be made
	//B//  bug that probably needs attention
	////B	but not necessarily immediately
	//D//  helpful debugging info
	//O//  optimizations that can be made
	//C//  things that should be cleaned up (made more elegant, etc)
	//Q//  questions about functionality

Comments: (new style)
	// XXX -- this bug requires immediate attention (or reclassifcation)
	// XXX/BUG -- bug that probably needs attention
	// XXX/ADD -- this is an addition that should be made
	// XXX/OPT -- optimizations that can be made
	// XXX/CLN -- things that should be cleaned up
	// XXX/DEP -- machine dependent code (should be moved)
	// XXX/??? -- questions about functionality
	// EXP -- expectations (for parameters, etc)
	// DBG -- helpul debugging info
	// !!! -- important note

	// !!! - typically, comments should be followed with the
	//	 author's initials in parenthesis (feb)

	// !!! - however, it can generally be assumed that any
	//	 comments without an author's initials are probably
	//	 from the original author of the file


-----------------------------------------------------------------------------
Include files:

	Use <Name> for including stuff that is complete
	in itself (i.e. -- we don't care about the implementation,
	or where it comes from, as long as it has
	the desired functionality)
	Use "Name.H" to get the local version when
	we care about the internals.

-----------------------------------------------------------------------------
Notes About Releases:


From now on, whenever new changes are made that require
the major or minor version number to be bumped up, the
"things done" entries are moved out of the STATUS file,
and put into the CHANGES file, and the version number is then
bumped up in both the software and in STATUS.

Note that all versions listed here have an implied patchlevel of 0,
unless otherwise specified.  In other words, for version
v0.94, the software should say either "v0.94.0" or just "v0.94"
Any software releases with other patchlevel numbers
are intermediate development/test releases (generally not
meant for human consumption since they aren't fully tested)

The first number represents the major release number
(only updated when large revisions to the system are made)
The second number is incremented whenever a significant change
has been made, or lots of bugs have been fixed (enough to
justify a new release solely for that reason)

If a release is made with a patchlevel number, it is
intended as an intermediate bug-fix release only.  Generally,
however, if the fix is significant enough to warrant
a release, the minor version will be bumped up instead.


-----------------------------------------------------------------------------
Notes About Status:

In "STATUS" files, for "things to do" and "bugs", items with
a bullet (o)  are more important, and items with a dash (-)
are "maybe someday" items.  Finished items are also marked with a dash.

"things done" gets moved to "CHANGES" when each release version is updated,
so unless you managed to get a debugging release, it should
always be empty.
Also, generally, "things to test" should also be empty, because before
each release, these items should be tested and moved to either
the "bugs" category, or "things done" (and then on to CHANGES)          
                                                             
-----------------------------------------------------------------------------
Software updates (improvments/bug fixes/etc...)

Any changes made to any part of SOLO or the Shag/OS distribution will
be mailed back to the author for verification and inclusion in the
next release.  Under no circumstances (except with express written
permission of the author) should modified code be redistributed.
However, patches may supplied along with the redistributed code,
as long as the original code remains intact, and the patch contains
information about who created it, what it does, and why, along with
a note making it clear that the patch is not part of the official
distribution.

