[Reproducible-commits] [reproducible-website] 10/55: Minor tweaks regarding readability

[Chris Lamb]

This is an automated email from the git hooks/post-receive script.

lamby pushed a commit to branch master
in repository reproducible-website.

commit 76404deb938d1782f70d20f26d0f046676da38cb
Author: Paul Gevers <elbrus at debian.org>
Date:   Mon Nov 2 12:33:34 2015 +0100

    Minor tweaks regarding readability
---
 _docs/buy_in.md     | 14 +++++++-------
 _docs/plans.md      |  8 ++++----
 _docs/test_bench.md |  2 +-
 index.html          |  6 +++---
 4 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/_docs/buy_in.md b/_docs/buy_in.md
index c8fb3a7..9f285b1 100644
--- a/_docs/buy_in.md
+++ b/_docs/buy_in.md
@@ -4,7 +4,7 @@ layout: docs
 permalink: /docs/buy-in/
 ---
 
-Working on reproducible builds might look like a lot of effort with
+Working on *reproducible builds* might look like a lot of effort with
 little gain at first. While [this applies to many types of work related to
 security](https://www.schneier.com/blog/archives/2008/09/security_roi_1.html),
 there are already some good arguments and testimonies
@@ -35,7 +35,7 @@ embedded in iOS applications. Palo Alto Networks
 > Baidu’s cloud file sharing service for used by Chinese iOS/OS X
 > developers
 
-The purpose of reproducible builds is exactly to resist such attacks.
+The purpose of *reproducible builds* is exactly to resist such attacks.
 Recompiling these applications with a clean compiler would have made
 the problem easily visible, especially given the size of the added
 payload.
@@ -83,7 +83,7 @@ in production.
 “But how can I trust my compiler?”
 ----------------------------------
 
-A common question related to reproducible builds is how is it possible
+A common question related to *reproducible builds* is how is it possible
 to know if the build environment is not compromised if everyone is using
 the same binaries? Or how can I trust that the compiler I just built
 was not compromised by a backdoor in the compiler I used to build it?
@@ -95,13 +95,13 @@ Ken Thompson published in 1984. It's the paper mentioned in the
 description of the talk about “Strawhorse” mentioned earlier.
 
 The technique known as [Diverse
-Double-Compilation](http://www.dwheeler.com/trusting-trust/) formally
-defined and researched by David A. Wheeler can answer this question.
+Double-Compilation](http://www.dwheeler.com/trusting-trust/), formally
+defined and researched by David A. Wheeler, can answer this question.
 To sum up quickly how it works: given two compilers, one trusted and
 one under test, the compiler under test is built twice,
 once with each compiler. Using the compilers created from this build,
 the compiler under test is built again. If the output is the same, then
 we have a proof that no backdoors have been inserted during the
 compilation. For this scheme to work, the output of the final
-compilations need to be the same. And that's exactly where reproducible
-builds are useful.
+compilations need to be the same. And that's exactly where *reproducible
+builds* are useful.
diff --git a/_docs/plans.md b/_docs/plans.md
index f8b302c..521187e 100644
--- a/_docs/plans.md
+++ b/_docs/plans.md
@@ -4,11 +4,11 @@ layout: docs
 permalink: /docs/plans/
 ---
 
-The idea of “reproducible” builds is to empower anyone to verify that no
+The idea of *reproducible builds* is to empower anyone to verify that no
 flaws have been introduced during the build process by reproducing
 byte-for-byte identical binary packages from a given source.
 
-Achieving reproducible builds require cooperation from multiple roles
+Achieving reproducible builds requires cooperation from multiple roles
 involved in software production. On small projects, all these roles
 might be carried by a single person, but it helps to differentiate the
 responsibilities.
@@ -35,7 +35,7 @@ toolchain[^toolchain] itself is byte-for-byte identical, but its
 output has to stay the same.
 
 The build environment can either be defined while the software is being
-developed or recorded at build time.
+developed or it can be recorded at build time.
 
 Distributing the build environment
 ----------------------------------
@@ -66,4 +66,4 @@ ignore specific parts. Such operations must be both documented and
 scripted. The rationale and code must be easy to understand by
 reviewers.
 
-[^toolchain]: By *toolchain*, we mean any piece of software needed to create the build output.
+[^toolchain]: By *toolchain*, we mean all pieces of software needed to create the build output.
diff --git a/_docs/test_bench.md b/_docs/test_bench.md
index af2da02..04ded6b 100644
--- a/_docs/test_bench.md
+++ b/_docs/test_bench.md
@@ -5,7 +5,7 @@ permalink: /docs/test-bench/
 ---
 
 It is important to detect reproducibility problems in the build system
-before users to avoid any false alarms.
+before the users do, to avoid any false alarms.
 
 The method is usually as followed:
 
diff --git a/index.html b/index.html
index 08dac43..ebb8f99 100644
--- a/index.html
+++ b/index.html
@@ -39,7 +39,7 @@ layout: home
     <p>
       Most aspect of software verification is done on source code, as that is
       what humans can reasonably understand. But most of the time, computers
-      require software to be first built into long string of numbers to be
+      require software to be first built into long a string of numbers to be
       used. With <em>reproducible builds</em>, multiple parties can
       <strong>redo this process independently</strong> and ensure they
       <strong>all get <em>exactly</em> the same result</strong>. We can thus
@@ -58,7 +58,7 @@ layout: home
     </p>
     <p>
       <a href="/who/"><strong>Several free software projects</strong></a>
-      already or will soon provide reproducible builds.
+      already, or will soon, provide reproducible builds.
     </p>
   </div>
 </div>
@@ -75,7 +75,7 @@ layout: home
       First, the <strong>build system needs to be made entirely
       deterministic</strong>: transforming a given source must always
       create the same result. Typically, the current date and time must not be
-      recorded and outputs has to always be written in the same order.
+      recorded and output always has to be written in the same order.
     </p>
     <p>
       Second, the set of tools used to perform the build and more generally

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/reproducible/reproducible-website.git