Re: [libvirt] [PATCH 1/2] hacking: fix typos

Eric Blake wrote: No problem. I made a quick pass through it and fixed a bunch more: From: Jim Meyering <meyering(a)redhat.com&gt; Date: Tue, 9 Mar 2010 17:21:55 +0100 Subject: [PATCH] doc: fix more typos in HACKING * HACKING: More spelling/typo fixes. --- HACKING | 20 ++++++++++---------- 1 files changed, 10 insertions(+), 10 deletions(-) diff --git a/HACKING b/HACKING index 9ee87c1..b94487c 100644 --- a/HACKING +++ b/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. -- 1.7.0.2.329.gdaec6