Eric Blake wrote:
On 03/09/2010 09:22 AM, Jim Meyering wrote:
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:
Actually, the whole point is that HACKING and docs/hacking.html.in are more or less duplicates of one another, and someone volunteered to make HACKING be autogenerated from the html version. Therefore, patching HACKING is not worth much (otherwise I would have patched both files in the first place); but your grammar change to go from 'committing patches' to 'committing a patch' should be flowed back to the html version.
Good point. This should help me avoid making that mistake again.
From 1b2adcb9f09266099e6df9b2d53bacb39bf7421c Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering@redhat.com> Date: Tue, 9 Mar 2010 17:59:25 +0100 Subject: [PATCH] doc: fix typos in hacking.html.in; mark HACKING as read-only
* HACKING: Mark as read-only. Soon we'll generate it from... * docs/hacking.html.in: ... this file. More typo fixes. --- HACKING | 3 +++ docs/hacking.html.in | 15 ++++++++------- 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/HACKING b/HACKING index b94487c..5486d8e 100644 --- a/HACKING +++ b/HACKING @@ -1,3 +1,6 @@ +-*- buffer-read-only: t -*- vi: set ro: +DO NOT EDIT THIS FILE! IT IS GENERATED AUTOMATICALLY! + Libvirt contributor guidelines ============================== diff --git a/docs/hacking.html.in b/docs/hacking.html.in index 8771c54..f5ec635 100644 --- a/docs/hacking.html.in +++ b/docs/hacking.html.in @@ -117,7 +117,7 @@ </pre> <p> - 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. @@ -424,7 +424,7 @@ #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. @@ -533,7 +533,7 @@ - <h2><a name="committers">Libvirt committers guidelines</a></h2> + <h2><a name="committers">Libvirt committer guidelines</a></h2> <p> The AUTHORS files indicates the list of people with commit access right @@ -541,11 +541,12 @@ </p> <p> - The general rule for committing 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 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 where you donot have a very clear idea of + be good to go. If the patch touches a part of the code where you're not + the main maintainer, or where you do not have a very clear idea of how things work, it's better to wait for a more authoritative feedback though. Before committing, please also rebuild locally, run 'make check syntax-check', and make sure you -- 1.7.0.2.329.gdaec6