From 0be37833161a6dd8dd15a26a9ed71ea06009cb27 Mon Sep 17 00:00:00 2001
From: Eric Blake <eblake@redhat.com>
Date: Mon, 8 Mar 2010 17:02:44 -0700
Subject: [PATCH] hacking: fix typos

* docs/hacking.html.in (committers): Fix spelling and grammar.
---
 HACKING              |  4 ++--
 docs/hacking.html.in | 26 +++++++++++++++-----------
 2 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/HACKING b/HACKING
index be8725dbd3..b6f63ddac1 100644
--- a/HACKING
+++ b/HACKING
@@ -369,8 +369,8 @@ of arguments.
 The AUTHORS files indicates the list of people with commit acces right
 who can actually merge the patches.
 
-The general rule for commiting patches is to make sure it has been reviewed
-properly in the mailing-list first, usually if a couple of persons gave an
+The general rule for commiting 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
diff --git a/docs/hacking.html.in b/docs/hacking.html.in
index 2016b2805f..15029ac534 100644
--- a/docs/hacking.html.in
+++ b/docs/hacking.html.in
@@ -514,38 +514,42 @@
 
 
 
-    <h2><a name="committers">Libvirt commiters guidelines</a></h2>
+    <h2><a name="committers">Libvirt committers guidelines</a></h2>
 
     <p>
-      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.
     </p>
 
     <p>
-      The general rule for commiting patches is to make sure it has been reviewed
+      The general rule for committing patches is to make sure it has been reviewed
       properly in the mailing-list first, usually if a couple of persons 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
-      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
+      main maintainer, or where you donot have a very clear idea of
+      how things work, it's better
+      to wait for a more authoritative feedback though. Before committing, please
+      also rebuild locally, run 'make check syntax-check', and make sure you
+      don't raise errors. Try to look for warnings too; for example,
+      configure with
+<pre>
       --enable-compile-warnings=error
+</pre>
       which adds -Werror to compile flags, so no warnings get missed
     </p>
 
     <p>
-      Exceptions to that 'review and approval on the list first' is fixing failures
+      An exception to 'review and approval on the list first' is fixing failures
       to build:
     </p>
     <ul>
-      <li>if a recently commited patch breaks compilation on a platform
-        or for a given driver then it's fine to commit a minimal fix
+      <li>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</li>
       <li>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</li>
       <li>
         fixes for documentation and code comments can be managed