doc: fix more typos in HACKING

* HACKING: More spelling/typo fixes.
This commit is contained in:
Jim Meyering 2010-03-09 17:21:55 +01:00
parent e839e33a96
commit 2a13ecc9be

20
HACKING
View File

@ -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.