Fix: typos

From Colin Tuckley.

1 files changed, 12 insertions, 12 deletions

diff --git a/arch/ick2-arch.mdwn b/arch/ick2-arch.mdwn
index 1383fe5..844d76b 100644
--- a/arch/ick2-arch.mdwn
+++ b/arch/ick2-arch.mdwn
@@ -14,7 +14,7 @@ days. You don't want to use Ick2, but if you have opinions on what a
 CI system should be like, feedback is welcome.
 
 This document describes the architecture of Ick2. Specifically, the
-architecure for the upcoming ALPHA-1 release, not further than that.
+architecture for the upcoming ALPHA-1 release, not further than that.
 It is a capital mistake to design software before you have all the
 requirements. It biases the judgment. You can rarely have all the
 requirements a priori, you have to iterate to gather them. Designing
@@ -24,7 +24,7 @@ Background and justification
 -----------------------------------------------------------------------------
 
 This section should be written some day. In short, Lars got tired of
-Jenkins, and all competetitors are seem insufficient or somehow
+Jenkins, and all competetitors seem insufficient or somehow
 unpleasant. Then Daniel suggested a name and Lars is incapable of not
 starting a project if given a name for it.
 
@@ -63,7 +63,7 @@ a static website that is built using the ikiwiki software. The source
 of the web pages is stored in a git repo, and the generated HTML pages
 are published on a web server.
 
-This might be expressed as Ick2 configuration like this:
+This might be expressed as an Ick2 configuration like this:
 
     projects:
         website:
@@ -84,7 +84,7 @@ reused, but it will always be possible for users to define their own.
 
 Pipeline steps will be able to use variables (including environment
 variables) so that the code can be reused for many projects. The
-mechanism for to define variables and whcat variables are availble
+mechanism for defining variables and which variables are availble
 will be defined as the ALPHA-1 implementation progresses.
 
 
@@ -102,8 +102,8 @@ Ick2 ALPHA-1 definition
 This is the current working definition of the aim for the ALPHA-1
 version of Ick2:
 
-> ALPHA-1 of Ick2 can be deployed and configured easily, and can build
-> concurrently multiple projects using multiple workers. Builds may be
+> ALPHA-1 of Ick2 can be deployed and configured easily, and can
+> concurrently build multiple projects using multiple workers. Builds may be
 > traditional builds from source code, may involve running unit tests
 > or other build-time tests, may involve building Debian packages, and
 > build artifacts are published in a suitable location. Builds may
@@ -176,17 +176,17 @@ self-modifying microservices.
 
 * The project's pipelines do things like: prepare workspace, run
   actual build, publish build artifacts from worker to a suitable
-  server. The controller keeps track of the where in each pipeline a
+  server. The controller keeps track of where in each pipeline a
   build is.
 
-* Workers are represented by worker-managers, which request work to do
+* Workers are represented by worker-managers, which request work
   from the controller and perform the work by running commands locally
   or over ssh on the actual worker host. Worker-managers may be on the
   worker hosts or elsewhere, depending on what suits best for each CI
   cluster.
 
 * Worker-builders register their workers with the controller. For
-  ALPHA-1 all workers are assumed to be equivalen
+  ALPHA-1 all workers are assumed to be equivalent
 
 * A pipeline is a sequence of steps (such as shell commands to run),
   plus some requirements for what attributes the worker that runs the
@@ -206,14 +206,14 @@ Ick2 consists of several independent services. This document describes
 how they are used individually and together.
 
 * The **controller** keeps track of projects, build pipelines, workers,
-  and the current state of each. It decides what build step is next,
+  and the current state of each. It decides which build step is next,
   and who should execute it. The controller provides a simple,
   unconditional "build this pipeline" API call, to be used by the
   trigger service (see below).
 
 * A **worker-manager** represents a **build host**. It queries the
   controller for work, and makes the build host (the actual worker)
-  execute it, and then reports results back to the worker.
+  execute it, and then reports results back to the controller.
 
 * The **trigger service** decides when a build should start. It polls
   the state of the universe, or gets notifications of changes of the
@@ -298,7 +298,7 @@ client -> IDP : GET /auth, with Basic Auth, over https
 IDP --> client : signed JWT token
 @enduml
 
-All API calls need a token. Getting a token happen the same way for
+All API calls need a token. Getting a token happens the same way for
 every API client.