fix spelling mistakes

master/docs/manual/concepts.rst

@@ -650,9 +650,9 @@ see :ref:`wamp <MQ-Specification>`
 There are then several strategy for introducing multimaster in your buildbot infra.
 A simple way to say it is by adding the concept of symetrics and asymetrics multimaster (like there is SMP and AMP for multi core CPUs)
 
-Symetric multimaster is when each master share the exact same configuration. They run the same builders, same schedulers, same everything, the only difference is that workers are connected evenly between the masters (by any means (e.g. DNS loadbalancing, etc)) Symetric multimaster is good to use to scale buildbot horizontally.
+Symetric multimaster is when each master share the exact same configuration. They run the same builders, same schedulers, same everything, the only difference is that workers are connected evenly between the masters (by any means (e.g. DNS load balancing, etc)) Symetric multimaster is good to use to scale buildbot horizontally.
 
-Asymetric multimaster is when each master have different configuration. Each master may have a specific responsability (e.g schedulers, set of builder, UI). This was more how you did in 0.8, also because of its own technical limitations. A nice feature of asymetric multimaster is that you can have the UI only handled by some masters.
+Asymetric multimaster is when each master have different configuration. Each master may have a specific responsibility (e.g schedulers, set of builder, UI). This was more how you did in 0.8, also because of its own technical limitations. A nice feature of asymetric multimaster is that you can have the UI only handled by some masters.
 
 Separating the UI from the controlling will greatly help in the performance of the UI, because badly written BuildSteps?? can stall the reactor for several seconds.
 
@@ -661,15 +661,15 @@ You would scale the number of UI master according to your number of UI users, an
 
 Depending on your workload and size of master host, it is probably a good idea to start thinking of multimaster starting from a hundred workers connected.
 
-Multimaster can also be used for high availibility, and seemless upgrade of configuration code.
+Multimaster can also be used for high availability, and seamless upgrade of configuration code.
 Complex configuration indeed requires sometimes to restart the master to reload custom steps or code, or just to upgrade the upstream buildbot version.
 
 In this case, you will implement following procedure:
 
 * Start new master(s) with new code and configuration.
 * Send a graceful shutdown to the old master(s).
 * New master(s) will start taking the new jobs, while old master(s) will just finish managing the running builds.
-* As an old master is finishing the running builds, it will drop the connections from the workers, who will then reconnect automatically, and by the mean of loadbalancer will get connected to a new master to run new jobs.
+* As an old master is finishing the running builds, it will drop the connections from the workers, who will then reconnect automatically, and by the mean of load balancer will get connected to a new master to run new jobs.
 
 As buildbot nine has been designed to allow such procedure, it has not been implemented in production yet as we know.
 There is probably a new REST api needed in order to graceful shutdown a master, and the details of gracefully dropping the connection to the workers to be sorted out.

master/docs/spelling_wordlist.txt

@@ -30,6 +30,11 @@ arguent
 argv
 ascii
 Async
+asymetrics
+Asymetric
+Asymetric
+asymetric
+Async
 Atlassian
 attricutes
 attrs
@@ -393,6 +398,7 @@ internet
 ini
 intialization
 intialized
+io
 ip
 IProperties
 iptables
@@ -496,6 +502,7 @@ multi
 Multi
 multiline
 Multimaster
+multimaster
 munge
 mutualisation
 mv
@@ -766,6 +773,9 @@ SVN
 svnmailer
 svnurl
 symlinks
+symetric
+Symetric
+symetrics
 synchronisation
 synchronise
 Synchronise