some clarification

1 files changed, 8 insertions, 13 deletions

diff --git a/readme.md b/readme.md
index 22f4ffd..a4d93fb 100644
--- a/readme.md
+++ b/readme.md
@@ -10,7 +10,7 @@ E: Failed to fetch http://dev.packages.vyos.net/repositories/sagitta/dists/sagit
 E: The repository 'http://dev.packages.vyos.net/repositories/sagitta sagitta InRelease' is not signed.
 ```
 
-Then don't be surprised. Are you not blocked - everyone is blocked. This is due to 
+Then don't be surprised - you aren't blocked - everyone is blocked. This is due to 
 [change in VyOS policy](https://blog.vyos.io/community-contributors-userbase-and-lts-builds) where
 they don't offer their `dev.packages.vyos.net/repositories` for public anymore. This change applies only to stable
 branches (like 1.3 equuleus/1.4 sagitta), you can still build current/development branch as usual with
@@ -29,9 +29,7 @@ as result you get apt repository that can be used to build ISO images.
 
 The goal of this project is to reproduce package repositories of stable branches formerly available at
 `dev.packages.vyos.net`. This isn't exactly possible due to the state of VyOS build system and VyOS packages.
-Many patches and workarounds for the build system were required to be developed and couple packages were required
-to be forked due to their broken or non-existent build script. Thus, for some packages slight variation exist. 
-In result, it's possible to recreate nearly identical replacement for `dev.packages.vyos.net` and produce ISO images
+The result isn't exactly the same but it's nearly identical replacement for `dev.packages.vyos.net` and it produces ISO images
 that are expected to be equivalent but of course with any custom image build you need to verify and test the resulting 
 image yourself.
 
@@ -48,10 +46,7 @@ either. This risk isn't likely, but it does exist since you will execute code fr
 The hardware requirements are significant - 8GB RAM, 100GB HDD and appropriate CPU. You will need 16GB of RAM but
 this doesn't need to be RAM, you can do 8GB RAM + 8GB swap, and you will still get good performance this way.
 
-I assume single shared host for Jenkins and x86 node (Built-In Node). I also assume the SSH host for reprepro
-repositories is the same as the Jenkins host. It's the simple way to get simple environment started all in one. 
-Normally you would have these roles split into more VMs but that's redundant for our purpose and thus everything is 
-on one host under one single user.
+Originally this setup was designed to use 3 or more virtual machines that's why some part may seem bit unusual. This guide merges everything to single host under single user to make it simpler and faster to get started. You may use another machine as build node for Jenkins (or multiple nodes), you may also use dedicated machine for reprepro but here it's assumed everything is one host and one user.
 
 Before you install Jenkins, create its user and group
 --
@@ -213,7 +208,7 @@ Configure Built-In node
 
 Separated by space thus "Docker docker ec2_amd64" as result
 
-Configure DEV_PACKAGES_VYOS_NET_HOST variable and add global vyos-build Jenkins library
+Configure environment variables and add global vyos-build Jenkins library
 --
 **Manage Jenkins -> System**
 
@@ -267,12 +262,12 @@ since some packages will use current and some sagitta branch.
 
 **Declarative Pipeline (Docker)**
 
-(this applies only if using patched vyos-build docker image)
-
 ```
 Docker registry URL: http://172.17.17.17:5000
 ```
 
+This will allow Jenkins to use your own (patched) vyos-build docker image. 
+
 Credentials for ssh-agent
 --
 You need to set up SSH key authentication for the host specified in `DEV_PACKAGES_VYOS_NET_HOST` variable.
@@ -610,14 +605,14 @@ git checkout equuleus
 ```
 
 There is known issue with smoketest that it will fail if you have too many CPU cores/threads. The test is designed
-to use half of your cores, but it will fail if calculates more than 4, thus if you have 6 or more cores/threads
+to use half of your cores, but it will fail if calculates more than 4, thus if you have 8 or more cores/threads
 then test likely will fail. If you do apply this patch to cap cores to 3:
 
 ```
 sed -i 's~cpu /= 2~cpu = 3~' scripts/check-qemu-install
 ```
 
-More cores don't increase speed, the test is single process anyway, it usually uses <2 cores and thus 3 is more than
+More cores don't increase speed, the test is single threas anyway, it usually uses <2 cores and thus 3 is more than
 enough. More cores will not speed up the test - it will only make the test fail due to OOM
 inside the test virtual machine.