External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2025-02-22 03:12:22 +00:00
Code Issues Packages Projects Releases Wiki Activity

hacking: fix typos

Browse Source 
* docs/hacking.html.in (committers): Fix spelling and grammar.
This commit is contained in:
Eric Blake 2010-03-08 17:02:44 -07:00 committed by Jim Meyering
parent 618dc80c2f
commit 0be3783316
2 changed files with 17 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
HACKING
View File

@ -369,8 +369,8 @@ of arguments.
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
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

26
docs/hacking.html.in
View File

@ -514,38 +514,42 @@
<h2><a name="committers">Libvirt commiters guidelines</a></h2>
<h2><a name="committers">Libvirt committers guidelines</a></h2>
<p>
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.
</p>
<p>
The general rule for commiting patches is to make sure it has been reviewed
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
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
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
main maintainer, or where you donot 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
don't raise errors. Try to look for warnings too; for example,
configure with
<pre>
--enable-compile-warnings=error
</pre>
which adds -Werror to compile flags, so no warnings get missed
</p>
<p>
Exceptions to that 'review and approval on the list first' is fixing failures
An exception to 'review and approval on the list first' is fixing failures
to build:
</p>
<ul>
<li>if a recently commited patch breaks compilation on a platform
or for a given driver then it's fine to commit a minimal fix
<li>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</li>
<li>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</li>
<li>
fixes for documentation and code comments can be managed