mirror of https://gitee.com/openkylin/libvirt.git
doc: fix more typos in HACKING
* HACKING: More spelling/typo fixes.
This commit is contained in:
parent
e839e33a96
commit
2a13ecc9be
20
HACKING
20
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.
|
||||
|
|
Loading…
Reference in New Issue