* docs/hacking.html.in (committers): Fix spelling and grammar.
---
Per the very text I'm editing, this counts as trivial :)
docs/hacking.html.in | 26 +++++++++++++++-----------
1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/docs/hacking.html.in b/docs/hacking.html.in
index 2016b28..15029ac 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
--
1.6.6.1