提交 2a13ecc9 编写于 作者: J Jim Meyering

doc: fix more typos in HACKING

* HACKING: More spelling/typo fixes.
上级 e839e33a
...@@ -96,7 +96,7 @@ around operators and keywords: ...@@ -96,7 +96,7 @@ around operators and keywords:
--no-tabs "$@" --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. piping it through "expand -i", since some leading TABs can get through.
Usually they're in macro definitions or strings, and should be converted Usually they're in macro definitions or strings, and should be converted
anyhow. anyhow.
...@@ -342,7 +342,7 @@ complexity it's best to stick to the following general plan for all ...@@ -342,7 +342,7 @@ complexity it's best to stick to the following general plan for all
#include <limits.h> #include <limits.h>
#if HAVE_NUMACTL Some system includes aren't supported #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 #endif
#include "internal.h" Include this first, after system includes. #include "internal.h" Include this first, after system includes.
...@@ -377,18 +377,18 @@ of arguments. ...@@ -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. 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 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 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 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 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 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 don't raise error. Try to look for warnings too for example configure with
--enable-compile-warnings=error --enable-compile-warnings=error
...@@ -396,13 +396,13 @@ which adds -Werror to compile flags, so no warnings get missed ...@@ -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 Exceptions to that 'review and approval on the list first' is fixing failures
to build: 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 or for a given driver then it's fine to commit a minimal fix
directly without getting the review feedback first 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 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 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 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. in the same way, but still make sure they get reviewed if non-trivial.
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册