Eric Blake wrote:
> On 03/09/2010 09:03 AM, Jim Meyering wrote:
>> The AUTHORS files indicates the list of people with commit acces right
>> who can actually merge the patches.
>>
>> -The general rule for commiting patches is to make sure it has been reviewed
>> -properly in the mailing-list first, usually if a couple of persons gave an
>> +The general rule for commiting a patch is to make sure it has been reviewed
>> +properly in the mailing-list first, usually if a couple of people gave an
>
> Sorry for not spotting it sooner, but s/commiting/committing/ (2 t's)
No problem.
I made a quick pass through it and fixed a bunch more:
>From 7f2ae0da9097a4aea87f25adab0f50881a8b7ccf Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@xxxxxxxxxx>
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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list