devops/build: Caught up "host" procedure. Order of "plugin"...

...declarations matters not.  Build hosts order builds by the
timestamps on the source distributions.  A Debian native package has
no Debian revision number.  Putting the package install script in a
bin/ writable by the build monkey is hardly an impediment to an evil
build monkey.  Commented out unimplemented source checks (copyright
notice and manual deffns).

diff --git a/src/devops/build.texi b/src/devops/build.texi
index 7aaf6e11eb04f0f013819fde02ac483ebf774be9..e18edb944ddb6e30c0f8801dda28e23a0ec79d98 100644 (file)
--- a/src/devops/build.texi
+++ b/src/devops/build.texi
@@ -82,21 +82,15 @@ Adds a plugin to the project.  @var{Name} should be a string.  It will
 be concatenated with the project name and a hyphen to create package
 file names.  @var{Directory} should be a string naming a subdirectory
 of the repository, the root of the plugin source tree.
-
-There is no dependency checking at the moment.  Plugins should be
-added in an order that satisfies their dependencies.  If a plugin
-depends on another, it should be added after the other so that new
-releases of the other will be built and installed before it.
 @end deffn
 
-@deffn Procedure host name user directory sarch darch ubuntu?
+@deffn Procedure host name user directory arch os
 This procedure adds a build host to the project.  New sources will be
 uploaded to @code{@var{user}@@@var{name}:@var{directory}/} using
-passwordless @code{scp}.  @var{Sarch} should be the Scheme
-architecture (@code{"i386"} or @code{"x86-64"}), @var{darch} the
-Debian architecture (from @code{dpkg-architecture -qDEB_TARGET_ARCH}).
-@var{Ubuntu?} should be @code{#t} if the host will be building Debian
-packages; else @code{#f}.
+passwordless @code{scp}.  @var{Arch} should be the Scheme architecture
+(e.g. @code{"i386"} or @code{"svm1-64"}).  @var{Os} is a string naming
+the host's operating system.  If it starts with @code{"Ubuntu"} and
+mentions a recent Ubuntu version, the host will build Debian packages.
 @end deffn
 
 @node Release Process
@@ -109,7 +103,7 @@ previous release tag.  That chain should be reviewed for changes or
 enhancements that deserve mention in the NEWS file or documentation.
 
 Often a chain of commits represents an enhancement that is immediately
-put to use in existing code.  The core might offer a new service and
+put to use in new code.  The core might offer a new service and
 several plugins take advantage of it.  The release process should tag
 a new core version first, update the plugins with the new core
 version dependency, then tag the new versions of the plugins.
@@ -173,7 +167,7 @@ On an Ubuntu host the builder must be able to install new packages
 using passwordless @code{sudo}.  This might be arranged with an
 entry in @file{/etc/sudoers}, e.g.
 @example
-puck ALL=(root) NOPASSWD: /usr/local/bin/mit-scheme-pucked-install
+puck ALL=(root) NOPASSWD: /usr/local/sbin/mit-scheme-pucked-install
 @end example
 and a short script, e.g.
 @example
@@ -186,14 +180,14 @@ exec dpkg --install "/home/puck/mit-scheme/$1"
 9.2.2, recently created from the @code{release-9.2} branch of the
 MIT/GNU Scheme project repository on Savannah.  Debian packages and
 source and binary distributions for 9.2.2 can be found on the pucked
-project web site.  @uref{http://birchwood-abbey.net/~matt/Scheme/}
+project web site.  @uref{http://birchwood-abbey.net/~puck/Scheme/}
 
 @node Lint Detection
 @section Lint Detection
 
 All of the devops release procedures warn of ``lint'' in the source
-code and documentation.  This includes out-of-date version numbers,
-copyright notices, etc.
+code and documentation.  At the moment, only out-of-date version
+numbers are detected.
 
 @menu
 * Core Lint::
@@ -208,13 +202,12 @@ The following checks are performed on a core Scheme source tree.
 The project version numbers in the documentation (@file{version.texi})
 and source (@file{runtime/version.scm}), and in
 @file{debian/changelog} should match.
-@c The Debian revision should always be 1?
 
 If there is a change in any file in the core source, the
 project version should have been incremented.
 
-All files should contain a header with the same copyright notice and
-the notice should include the current year.
+@c All files should contain a header with the same copyright notice and
+@c the notice should include the current year.
 @c Unless no file has changed since the last year in the notice?
 
 @node Plugin Lint
@@ -229,13 +222,13 @@ and source (@file{make.scm}), in @file{NEWS} and
 If there is a change in any file in the plugin source, the plugin
 version should have been incremented.
 
-All files should contain a header with the same copyright notice and
-the notice should include the current year.
+@c All files should contain a header with the same copyright notice and
+@c the notice should include the current year.
 @c Unless no file has changed since the last year in the notice?
 
-The source includes all GNU standard files, @file{README},
-@file{ChangeLog}, @file{AUTHORS}, @file{COPYING} and @file{NEWS} are
-present in the customary format.
+@c The source includes all GNU standard files, @file{README},
+@c @file{ChangeLog}, @file{AUTHORS}, @file{COPYING} and @file{NEWS} are
+@c present in the customary format.
 
-The plugin should have a manual containing a @code{@@deffn} section
-for every binding it exports to the global environment.
+@c The plugin should have a manual containing a @code{@@deffn} section
+@c for every binding it exports to the global environment.