doc: fix more typos in HACKING

* HACKING: More spelling/typo fixes.

diff --git a/HACKING b/HACKING
index 9ee87c1061cbb11585fe75e4cff2842dcc2c4951..b94487cc21ed7506c8222df695a2e71b5a6e9c16 100644 (file)
--- a/HACKING
+++ b/HACKING
@@ -96,7 +96,7 @@ around operators and keywords:
       --no-tabs "$@"
   }
 
-Note that sometimes you'll have to postprocess that output further, by
+Note that sometimes you'll have to post-process that output further, by
 piping it through "expand -i", since some leading TABs can get through.
 Usually they're in macro definitions or strings, and should be converted
 anyhow.
@@ -342,7 +342,7 @@ complexity it's best to stick to the following general plan for all
   #include <limits.h>
 
   #if HAVE_NUMACTL                Some system includes aren't supported
-  #include <numa.h>               everywhere so need these #if defences.
+  # include <numa.h>              everywhere so need these #if guards.
   #endif
 
   #include "internal.h"           Include this first, after system includes.
@@ -377,18 +377,18 @@ of arguments.
 
 
 
-                Libvirt commiters guidelines
+                Libvirt committer guidelines
                 ============================
 
-The AUTHORS files indicates the list of people with commit acces right
+The AUTHORS files indicates the list of people with commit access right
 who can actually merge the patches.
 
-The general rule for commiting a patch is to make sure it has been reviewed
+The general rule for committing a patch is to make sure it has been reviewed
 properly in the mailing-list first, usually if a couple of people gave an
 ACK or +1 to a patch and nobody raised an objection on the list it should
 be good to go. If the patch touches a part of the code where you're not the
 main maintainer or not have a very clear idea of how things work, it's better
-to wait for a more authoritative feedback though. Before commiting please
+to wait for a more authoritative feedback though. Before committing please
 also rebuild locally and run 'make check syntax-check' and make sure they
 don't raise error. Try to look for warnings too for example configure with
    --enable-compile-warnings=error
@@ -396,13 +396,13 @@ which adds -Werror to compile flags, so no warnings get missed
 
 Exceptions to that 'review and approval on the list first' is fixing failures
 to build:
-  - if a recently commited patch breaks compilation on a platform
+  - if a recently committed patch breaks compilation on a platform
     or for a given driver then it's fine to commit a minimal fix
     directly without getting the review feedback first
-  - similary if make check or make syntax-check breaks, if there is
+  - similarly, if make check or make syntax-check breaks, if there is
     an obvious fix, it's fine to commit immediately
 The patch should still be sent to the list (or tell what the fix was if
-trivial) and 'make check syntax-check' should pass too before commiting
+trivial) and 'make check syntax-check' should pass too before committing
 anything
-Similary fixes for documentation and code comments can be managed
+Similar fixes for documentation and code comments can be managed
 in the same way, but still make sure they get reviewed if non-trivial.