From: Matt Birkholz Date: Sun, 1 Oct 2017 16:42:29 +0000 (-0700) Subject: devops/build: Caught up "host" procedure. Order of "plugin"... X-Git-Tag: mit-scheme-pucked-9.2.12~49 X-Git-Url: https://birchwood-abbey.net/git?a=commitdiff_plain;h=d08aa661a2fd83a20ed81b87c4c58a42bc02aaef;p=mit-scheme.git 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 7aaf6e11e..e18edb944 100644 --- 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.