[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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 redhat com>
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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]