diff options
| -rw-r--r-- | HACKING | 4 | ||||
| -rw-r--r-- | docs/hacking.html.in | 26 |
2 files changed, 17 insertions, 13 deletions
@@ -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 diff --git a/docs/hacking.html.in b/docs/hacking.html.in index 2016b2805..15029ac53 100644 --- a/docs/hacking.html.in +++ b/docs/hacking.html.in @@ -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 |