Better new-pocket affordances in invirtibuilder and build submission script

[invirt/packages/invirt-dev.git] / README.invirtibuilder

diff --git a/README.invirtibuilder b/README.invirtibuilder
index 0a853bf..72215e2 100644 (file)
--- a/README.invirtibuilder
+++ b/README.invirtibuilder
@@ -26,10 +26,10 @@ design of the Invirtibuilder:
 
   Because of how Git tracks history, it's better suited for tracking a
   series of small repositories, as opposed to one large one
-  [#]_. Furthermore, most pre-existing tools and techniques for
-  dealing with Debian packages in Git repositories (such as
-  git-buildpackage_ or `VCS location information`_) are designed
-  exclusively for this case.
+  [#]_. Furthermore, most preexisting tools and techniques for dealing
+  with Debian packages in Git repositories (such as git-buildpackage_
+  or `VCS location information`_) are designed exclusively for this
+  case.
 
 * Synchronization between Git and APT repositories.
 
@@ -92,7 +92,7 @@ Configuration
 
 For the Invirt_ project's use of the Invirtibuilder, we adapted our
 existing configuration mechanism. Our configuration file consists of a
-singls YAML_ file. Here is the snippet of configuration we use for our
+single YAML_ file. Here is the snippet of configuration we use for our
 build configuration::
 
  build:
@@ -172,7 +172,7 @@ We considered several ways to trigger builds of new package versions
 using Git directly. However, we realized that what we actually wanted
 was a separate build queue where each build request was handled and
 processed independently of any requests before or after it. It's not
-possible to have these semantics using Git as a signalling mechanism
+possible to have these semantics using Git as a signaling mechanism
 without breaking standard assumptions about how remote Git
 repositories work.
 
@@ -185,7 +185,7 @@ server with a pocket, a package, and a commit ID from that package's
 Git repository. The remctl daemon then calls a script which validates
 the build and adds it to the build queue. Because of the structure of
 remctl's ACLs, we are able to have different ACLs depending on which
-pocket the build is destined for. This allows us to fulfil our design
+pocket the build is destined for. This allows us to fulfill our design
 goal of having different ACLs for different pockets.
 
 For simplicity, the queue itself is maintained as a directory of
@@ -268,7 +268,7 @@ Once the build has been successfully completed, the APT and Git
 repositories are updated to match the new state. First, a new tag is
 added to the package's Git repository for the current version
 [#]_. Next, the pocket tracking branch in the submodule is also
-updated with the new version of the package. Then the a new commit is
+updated with the new version of the package. Then a new commit is
 created on the superproject which updates the package's submodule to
 point to the new version of the package. Finally, the new version of
 the package is included in the appropriate component of the APT
@@ -296,7 +296,7 @@ As noted above, our intent was for a single instance of the
 Invirtibuilder to be used for both our trusted production environment
 and our untrusted development environment. In order to be trusted for
 the production environment, the Invirtibuilder needs to run in the
-production environment as well. However, it would be disasterous if
+production environment as well. However, it would be disastrous if
 access to the development environment allowed a developer to insert
 malicious packages into the production apt repository.