MANIFEST:

Initial checkin. Explains what the various file here are.

adding.utils:
	Initial checkin. Discusses stuff necessary to add utils to the
	base distribution.

doing.builds:
	Initial checkin. Explains how to create the base builds.

NOTES/devel/MANIFEST

@@ -0,0 +1,7 @@
+MANIFEST	This file.
+TO.DO		A list of things that still have to be done for GNO.  These
+		really belong in the bugs database at http://www.gno.org
+		as either bugs or feature requests.
+adding.utils	Discusses stuff necessary to add utils to the base
+		distribution.
+doing.builds	Explains how to create the base builds.

NOTES/devel/adding.utils

@@ -0,0 +1,95 @@
+$Id: adding.utils,v 1.1 1999/01/09 21:19:58 gdr-ftp Exp $
+
+General
+-------
+
+You should read this file if you are contemplating adding utilities
+to the base GNO distribution.
+
+The first question is whether or not your utility belongs with the 
+base distribution.  The criteria are loose, but if it is a commonly
+used utility among the majority of GNO users, or if it is required
+for building GNO itself, it may be incorporated into the base
+distribution.  If you think your utility matches these criteria,
+contact Devin Reade <gdr@trenco.gno.org>.
+
+Source Code
+-----------
+
+There is no restriction to which source language you use.  If you have
+successfully written a program written in something other than ORCA/C
+or ORCA/M, please share your observations with the GNO development group
+regarding using these other languages.
+
+[talk about hierarchy in the src directory]
+
+It should be clear from the *source* exactly from where the original code
+came.  In the case of GNO base distribution utilities ported from BSD, 
+changes should be reviewed by the GNO development team.
+
+Mandetory Makefile Targets
+--------------------------
+
+
+Documentation Requirements
+--------------------------
+
+For utilities that become part of the GNO base distribution, there
+are three *required* documentation files:
+
+	1.  A manual page.  Ensure that it is using a format understood
+	    by the GNO version of nroff.  BSD manual pages do not 
+	    usually fall into this category.  Some utilities have both
+	    a GNO and a BSD man page.  In this case, the BSD man page
+	    has a suffix of (for example) ".1" while the GNO version
+	    has a suffix of ".1G".  In either case, the suffix of the
+	    manual page after installation should be ".1".  See the
+	    ftp(1) source for an example.
+	2.  A describe(1) entry.
+	3.  A rez source file containing an rVersion entry.  This
+	    will become (part of) the program's resource fork.
+	    This file may contain other resources as well.  Some
+	    common ones include rComment and rProgInfo entries.
+
+The GNO FAQ has information on where samples of these documentation
+files may be found.
+
+Other documentation files can be included as necessary.  These include
+but are not limited to READMEs, ChangeLogs, and reference manuals.
+
+The README or other documentation should contain the following information:
+	1.  Who wrote or ported the program.
+	2.  How the maintainer may be contacted.
+	3.  A list of what features have been tested.
+	4.  The copying status; is it freeware, public domain, shareware,
+	    copyleft, or something else?
+
+There should be a detailed record of what changes have been made for
+the various versions.  Small projects can have this information in the
+README file; large projects should use a separate ChangeLog.
+
+
+RCS/CVS Identifiers
+-------------------
+
+When you're working on your utils please include, in comments near the
+top of each file, the character sequence "[Dollar sign]Id[Dollar sign]"
+(minus the quotes, and with [Dollar sign] repaced by '$').  This is an
+RCS identifer.  (RCS is the Revision Control System.  CVS, the Concurrent
+Versions System, depends on RCS.)  Adding in the RCS identifier  will
+cause the version number associated with each file in the repository to
+be displayed (and automatically updated) in each file.
+
+You should *not* add a RCS identifier to your describe(1) entry file.
+These files are cat'd together later when creating the database,
+and the RCS identifiers do not belong in the database.
+
+Note that some sources (notably some BSD files) already have such a string.
+In these cases, you need not add another.  An expanded string looks
+something like this:
+
+        $Id: adding.utils,v 1.1 1999/01/09 21:19:58 gdr-ftp Exp $
+
+When the sources are released, a 'cvs export' will be done which will
+keep the version number intact, even if someone at a remote site decides
+to import it into their own repository.

NOTES/devel/doing.builds

@@ -0,0 +1,46 @@
+$Id: doing.builds,v 1.1 1999/01/09 21:19:58 gdr-ftp Exp $
+
+GNO has to be build in the following sequence.  (There are dependancies.)
+
+	../lib/orcalibs/Source
+	include
+	lib/lsaneglue
+	lib/libc
+	lib/libutil
+	lib/libedit
+
+
+- the default target in the makefiles causes the program or library 
+  to be built in the /obj hierarchy.
+
+- the 'release' target causes the final files to be placed into the
+  /dist hierarchy.
+
+- when the builds are closer to a sane state the /dist hierarchy
+  will be used to directly make a distribution.  However for now,
+  we make use of another hierarchy, /gno into which we copy the
+  /dist hierarchy.  The /gno hierarchy is then topped up with files
+  from a v2.0.4 distribution.
+
+- so, once the 'release' target has been made in all the relevent source
+  directories, the following must occur:
+
+	- start with an empty /gno directory.
+	- copy the entire contents of /dist to /gno
+	- make sure you have a /gno-hfs partition online
+	- run the /src/gno/build.tools/fudgeinstall script
+	- run the /src/gno/build.tools/mkboot script
+	- run the /src/gno/build.tools/mkdisk1 script
+	- go to the /gno directory.  Using gshk, archive all the 
+	  directories you find there (such as gno.01, gno.02, etc).
+	  You should create the files gno.01.shk, gno.02.shk, and so
+	  forth.  Don't include the upper directory name in the archive.
+	  When creating gno.16.shk, leave out the /install directory.
+	- go to the /gno-hfs partition.  Archive up all contents of that
+	  partition to create the gnohfs.shk archive.  The gnohfs.shk
+	  file should be placed with the gno.??.shk files from the 
+	  previous step.
+	- go to the /gno.boot partition and use gshk to archive all
+	  all the files in that partition.  Name the resulting archive
+	  file gnoboot.shk, and place it with the other archive files.
+	- run the /src/gno/build.tools/mkdisk2 script