From: Teemu Hukkanen <tjhukkan@iki.fi>
To: ick-discuss@ick.liw.fi
Date: Sat, 29 Sep 2018 08:15:54 +0200
Message-ID: <87wor4g76t.fsf@logic.part.iki.fi>
MIME-Version: 1.0
Subject: [PATCH] ick.liw.fi: Fix typos
Precedence: list
Content-Type: multipart/mixed; boundary="===============3973257231097315628=="
Mime-version: 1.0
Sender: ick-discuss-bounces@ick.liw.fi
Errors-To: ick-discuss-bounces@ick.liw.fi

--===============3973257231097315628==
Content-Type: text/x-diff
Content-Disposition: inline; filename=0001-Fix-typos.patch

>From 0d6ace13433e49d23fc1ea086bf2d2bc1224ea9a Mon Sep 17 00:00:00 2001
From: Teemu Hukkanen <tjhukkan@iki.fi>
Date: Sat, 29 Sep 2018 00:29:29 +0200
Subject: [PATCH] Fix typos

---
 architecture.mdwn | 66 +++++++++++++++++++++++------------------------
 ick_files.mdwn    | 10 +++----
 newuser.mdwn      |  2 +-
 patches.mdwn      |  6 ++---
 roadmap.mdwn      | 12 ++++-----
 5 files changed, 48 insertions(+), 48 deletions(-)

diff --git a/architecture.mdwn b/architecture.mdwn
index a04bb61..159966a 100644
--- a/architecture.mdwn
+++ b/architecture.mdwn
@@ -11,14 +11,14 @@ evolve into also being a tool for also doing continuous deployment
 
 This document describes the technical architecture of ick.
 Specifically, the architecture for the upcoming ALPHA-6 release, but
-not further than that. ALPHA-6 is meant to usable by people other than
-the primary developer.
+not further than that. ALPHA-6 is meant to be usable by people other
+than the primary developer.
 
 What is continuous integration?
 -----------------------------------------------------------------------------
 
-Continuous integration is a style software development where changes
-get integrated to the main line of development freuqently. It is
+Continuous integration is a software development style where changes
+get integrated to the main line of development frequently. It is
 contrasted with a style where features get developed in their own,
 long-living branches and only get integrated when finished, often
 after weeks or months of development. The latter often results in an
@@ -53,11 +53,11 @@ architecture that among other things only allowed running one build at
 a time, and did not work well as a service.
 
 The second (current) generation of ick is a re-design from scratch,
-keeping nothing of the first genearation. It is explicitly aimed to
+keeping nothing of the first generation. It is explicitly aimed to
 become a "hostable" system: to allow an ick instance to be a CI system
 to a number of independent users.
 
-The name "ick" was suggestd by Daniel Silverstone in an IRC
+The name "ick" was suggested by Daniel Silverstone in an IRC
 discussion. He said "all CI systems are icky", and this prompted Lars
 to name the first generation "ick".
 
@@ -68,7 +68,7 @@ Overview
 A continuous integration system is, at its most simple core, an
 automated system that reacts to changes in a program's source code by
 doing a build of the program, running any of its automated tests, and
-then publishing the results somewhere. A continuoues deployment system
+then publishing the results somewhere. A continuous deployment system
 continues from there to also installing the new version of the program
 on all relevant computers. If any step in the process fails, the
 system notifies the relevant parties.
@@ -77,7 +77,7 @@ Ick aims to be a CI system. It deals with a small number of concepts:
 
 * **projects**, which consist of **source code** in a version control
   system
-* **pipelines**, which are reuseable sequences of actions aiming to
+* **pipelines**, which are reusable sequences of actions aiming to
   achieve some task (build program source code, run tests, etc)
 * **workers**, which do all the actual work by executing pipeline
   actions
@@ -244,9 +244,9 @@ how they are used individually and together.
   hopefully happen not too far in the future.)
 
 * The **icktool** command line tool provides the ick user interface.
-  It get an access token from the identity provider, and uses the
+  It gets an access token from the identity provider, and uses the
   controller and artifact store APIs to manage project and pipeline
-  descriptions, build artfifacts, trigger builds, and view build
+  descriptions, build artifacts, trigger builds, and view build
   status.
 
 [Qvisqve]: http://qvarn.org/qvisqve
@@ -384,7 +384,7 @@ every API client. There are three exceptions:
   the IDP.
 * Triggering a project to build. This is temporarily un-authenticated,
   to avoid having to distribute API credential to git server. This
-  willl be fided later.
+  will be fixed later.
 
 
 Getting an access token: ickui and OpenID Connect
@@ -397,12 +397,12 @@ than the client credentials grant for non-interactive use.
 
 [OpenID Connect]: https://openid.net/specs/openid-connect-core-1_0.html
 
-In summary, there are five entitities involved:
+In summary, there are five entities involved:
 
 * the end-user who owns (in a legal meaning) the resources involved
 * the "resource server" where the resources technically are: this
   means the controller and artifact store, and possibly other ick
-  compontents that hold data on behalf of the end-user
+  components that hold data on behalf of the end-user
 * the IDP (Qvisqve), which authenticates the end-user and gives out
   access tokens that allow the bearer of the access token to do things
   with the user's resources
@@ -411,7 +411,7 @@ In summary, there are five entitities involved:
 * a "facade" that sits between the browser and the resource servers
 
 The facade is necessary for security. We do not trust the browser to
-be keep an access token secure from malware running on the end-user's
+keep an access token secure from malware running on the end-user's
 machine or device, including in the browser. The facade runs on what
 is assumed to be a more secure machine, and can thus be trusted with
 the access token. The facade can also provide a more convenient API
@@ -423,8 +423,8 @@ front-end, and includes the access token to those.
 
 * User initiates login, by clicking on a "login" link in the front-end
   UI. Or else the facade initiates this, when its access token
-  expires. Either way, the browser makes a request the facade's login
-  endpoint.
+  expires. Either way, the browser makes a request to the facade's
+  login endpoint.
 * Facade redirects user's browser to Qvisqve.
     * This is called the "authorization request". It includes some
       data that's needed to prevent various security intrusions.
@@ -498,21 +498,21 @@ parameters. If it looks OK, Qvisqve creates an "authorization attempt
 object", and stores `CLIENTID`, `RANDOMSTRING`, and `CALLBACKURI` in
 it. It also generates an object id (a UUID4).
 
-Qvisvqe returns to the browser a login form, asking for username and
+Qvisqve returns to the browser a login form, asking for username and
 password, plus a hidden form field with the authorization attempt
 object id.
 
 The user fills in the login form, and submits it. The submitted form
-includes the authorization attempt object id field. Qvisqve checks the
-id value corresponds to an existing authorization attempt object, and
-that the credentials are valid. If so, it creates an authorization
-code, stores that into the authorization object, and responds the form
-submission with:
+includes the authorization attempt object id field. Qvisqve checks
+that the id value corresponds to an existing authorization attempt
+object, and that the credentials are valid. If so, it creates an
+authorization code, stores that into the authorization object, and
+responds to the form submission with:
 
     HTTP/1.1 302 Found
     Location: CALLBACKURI?code=AUTHZCODE&state=RANDOMSTRING
 
-Here, `CALLBACKURI` and `RANDOMSTRING` are the retrieved from the
+Here, `CALLBACKURI` and `RANDOMSTRING` are the ones retrieved from the
 authorization object.
 
 Browser follows the redirect to the facade. The facade checks that
@@ -536,9 +536,9 @@ Qvisqve. The client id must be the same as given in the initial
 authorization request.
 
 Qvisqve checks the client's credentials (`Authorization` header), and
-the `AUTHZCODE` is one it has generated and that hasn't yet been used,
-and that `CALLBACKURI` is registered with the facade. If all is well,
-it responds the facade's token request:
+that the `AUTHZCODE` is one it has generated and that hasn't yet been
+used, and that `CALLBACKURI` is registered with the facade. If all is
+well, it responds to the facade's token request:
 
     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
@@ -630,14 +630,14 @@ diagram.
                 deactivate resources
                 facade -> browser : some thing
             deactivate facade
-            broser -> enduser : show thing to user
+            browser -> enduser : show thing to user
         deactivate browser
 
     end
 
     @enduml
 
-(This should be the same protocol as descibed in prose above.)
+(This should be the same protocol as described in prose above.)
 
 The worker-manager
 -----------------------------------------------------------------------------
@@ -866,16 +866,16 @@ Ick controller resources and API
 
 See the example project for examples. Each item in the `projects` and
 `pipelines` lists is a resource. The example is in YAML syntax, but is
-trivially converted to JSON, which the API talks. (The exampel is
+trivially converted to JSON, which the API talks. (The example is
 input to the `icktool` command and is meant to be human-editable. YAML
 is better for that, than JSON.)
 
 For a fuller description of the APIs, see the [yarn][] scenario tests
 in the ick source code: <http://git.liw.fi/ick2/tree/yarns>
 
-A build resource is created automatically, when a project is triggerd,
-at `/builds/BUILDID`, a pipeline is triggered. It can't be changed via
-the API.
+A build resource is created automatically, when a project is
+triggered, at `/builds/BUILDID`, a pipeline is triggered. It can't be
+changed via the API.
 
     {
         "project": "liw.fi",
@@ -899,7 +899,7 @@ for now we'll have just the name.
         "worker": "bartholomew"
     }
 
-A work resource resource tells a worker what to do next:
+A work resource tells a worker what to do next:
 
     {
         "project": "liw.fi",
diff --git a/ick_files.mdwn b/ick_files.mdwn
index 55bb586..7313706 100644
--- a/ick_files.mdwn
+++ b/ick_files.mdwn
@@ -10,7 +10,7 @@ of pipelines.
 
 A project has a name, optionally defines some parameters, and lists
 one or more pipelines. A pipeline is a re-useable sequence of build
-actions to achieve a goal, such a checking out code from version
+actions to achieve a goal, such as checking out code from version
 control, or building binaries from source code.
 
 You can roughly think of a pipeline as a subroutine that the project
@@ -54,7 +54,7 @@ three possibilities:
 * `container` &ndash; in a container using a defined system tree
   (systree) and workspace bind-mounted at /workspace
 
-You should strive to run all actions in conatiners, since that makes
+You should strive to run all actions in containers, since that makes
 it hardest to mess up the worker host.
 
 Actions are run as root in the container, and in a chroot. On the
@@ -90,7 +90,7 @@ The worker manager defines (at least) the following actions:
 * `archive: workspace`
 
     Take the current content of the workspace, put it in a compressed
-    tar archive, and uplad it to the artifact store. Get the name of
+    tar archive, and upload it to the artifact store. Get the name of
     the artifact from the parameter named in the `name_from` field, if
     given, and the`artifact_name` parameter if not.
 
@@ -173,7 +173,7 @@ The worker manager defines (at least) the following actions:
     .mirror/$name && git remote update --prune`).
 
     Ick provides a pipeline that uses the `git_mirror` action and
-    addtional `shell` or `python` actions to do the checkout.
+    additional `shell` or `python` actions to do the checkout.
 
 * `action: rsync`
 
@@ -233,7 +233,7 @@ Build one for each target Debian release: `jessie`, `stretch`,
 store with systree artifacts. Each actual project should use one of
 the artifacts to do the build in a container.
 
-You can use the `ick/build_debian_systree` pipeline to build systreees
+You can use the `ick/build_debian_systree` pipeline to build systrees
 with Debian.
 
 When building in a container, you can install more things inside the
diff --git a/newuser.mdwn b/newuser.mdwn
index 5531e50..2788568 100644
--- a/newuser.mdwn
+++ b/newuser.mdwn
@@ -7,7 +7,7 @@ This page has instructions for using it. Thank you for helping me with
 ick.
 
 Ick is ALPHA level software, and keeps changing. Sorry about that. As
-part of process, the way ick is accessed is currently changing.
+part of that process, the way ick is accessed is currently changing.
 Everything in this page is likely to change in the coming weeks. Be
 prepared to learn new things, although we will try to avoid breaking
 things.
diff --git a/patches.mdwn b/patches.mdwn
index 54d99be..c69fb56 100644
--- a/patches.mdwn
+++ b/patches.mdwn
@@ -40,13 +40,13 @@ Here's a few ways you can send us changes:
   ick-discuss mailing list. (Using "git send-email" is good, too.)
 
   If you're sending a patch series consisting of several patches,
-  add a "cover letter" that expolains what the whole series is about.
+  add a "cover letter" that explains what the whole series is about.
 
 * Make the changes available on a different git server, and send us a
   URL we can pull from. You can use GitHub or any other server that's
   convenient for you. You can even create a pull request and send a
   URL to that. We prefer you send us the URL over e-mail to the
-  ick-dicusss mailing list, as that gets automatically tracked
+  ick-discuss mailing list, as that gets automatically tracked
 
 
 # On patches (and pull requests)
@@ -55,7 +55,7 @@ We prefer a patch series and pull request to tell a story of the
 change that is easy to follow and review and understand.
 
 * Each patch/commit should have a clear commit message. The commit
-  message should explain why the change is made, and not just repharse
+  message should explain why the change is made, and not just rephrase
   the diff. The commit message should stand on its own, as it will be
   read on its own in the future, when someone is debugging the
   program, possibly with "git bisect".
diff --git a/roadmap.mdwn b/roadmap.mdwn
index 065238a..79b126b 100644
--- a/roadmap.mdwn
+++ b/roadmap.mdwn
@@ -8,17 +8,17 @@ Ick is now usable by others. If you try ick and have problems, do tell
 us, see the [[contact]] page for contact information.
 
 Ick is by no means an abandoned project, but we're taking a breather
-while waiting for other developments. Most imporantly, ick will want a
+while waiting for other developments. Most importantly, ick will want a
 web UI, and that and other features will require end-user
 authentication. The Qvisqve software ick uses for authentication will
-be getting that support in 2018. Once it does, ick start adding
+be getting that support in 2018. Once it does, ick will start adding
 support for that.
 
 Until then, the plan is to make small, incremental improvements to
-ick, fix bugs, improve documentation, smooth rought corners, and
+ick, fix bugs, improve documentation, smooth rough corners, and
 gather experience on using ick.
 
-The long-term goal is to develp ick into a hosted service, which can
+The long-term goal is to develop ick into a hosted service, which can
 be run on a commercial basis, without compromising on software
 freedom.
 
@@ -51,7 +51,7 @@ freedom.
       label: |
         Ick supports building
         for multiple
-        architecturs.
+        architectures.
       depends:
         - worker_tags
         - concurrency
@@ -127,7 +127,7 @@ freedom.
         a git repo changes,
         or when an ick build
         finishes, or after
-        some time has psssed
+        some time has passed
 
     isolation:
       label: |
-- 
2.19.0



--===============3973257231097315628==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ick-discuss mailing list
ick-discuss@ick.liw.fi
https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/ick-discuss-ick.liw.fi

--===============3973257231097315628==--