Document somme commit rules, and add application monitoring links to docs

* HACKING: update with some rules for commiters
* docs/apps.html docs/apps.html.in: add a section on monitoring
  support
daniel

1 files changed, 34 insertions, 2 deletions

diff --git a/HACKING b/HACKING
index 1f9ac7b2e..3945833f2 100644
--- a/HACKING
+++ b/HACKING
@@ -1,5 +1,5 @@
-Libvirt contributor guidelines
-==============================
+                    Libvirt contributor guidelines
+                    ==============================
 
 
 General tips for contributing patches
@@ -245,3 +245,35 @@ Of particular note: *DO NOT* include libvirt/libvirt.h or
 libvirt/virterror.h.  It is included by "internal.h" already and there
 are some special reasons why you cannot include these files
 explicitly.
+
+
+
+                Libvirt commiters guidelines
+                ============================
+
+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
+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
+   --enable-compile-warnings=error
+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
+    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-chek 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
+anything
+Similary fixes for documentation and code comments can be managed
+in the same way, but still make sure they get reviewed if non-trivial.