General tips for contributing patches

	* HACKING: Added section "general tips for contributing patches"
	to this file.

1 files changed, 41 insertions, 1 deletions

diff --git a/HACKING b/HACKING
index c4ec6ca03..aabdcc2d9 100644
--- a/HACKING
+++ b/HACKING
@@ -2,6 +2,46 @@ Libvirt contributor guidelines
 ==============================
 
 
+General tips for contributing patches
+=====================================
+
+(1) Discuss any large changes on the mailing list first.  Post patches
+early and listen to feedback.
+
+(2) Post patches in unified diff format.  A command similar to this
+should work:
+
+  diff -urp libvirt.orig/ libvirt.modified/ > libvirt-myfeature.patch
+
+or:
+
+  cvs diff -up > libvirt-myfeature.patch
+
+(3) Split large changes into a series of smaller patches, self-contained
+if possible, with an explanation of each patch and an explanation of how
+the sequence of patches fits together.
+
+(4) Make sure your patches apply against libvirt CVS.  Developers
+only follow CVS and don't care much about released versions.
+
+(5) Run the automated tests on your code before submitting any changes.
+In particular, configure with compile warnings set to -Werror:
+
+  ./configure --enable-compile-warnings=error
+
+and run the tests:
+
+  make check
+  make syntax-check
+  make -C tests valgrind
+
+The latter test checks for memory leaks.
+
+(6) Update tests and/or documentation, particularly if you are adding
+a new feature or changing the output of a program.
+
+
+
 Code indentation
 ================
 Libvirt's C source code generally adheres to some basic code-formatting
@@ -198,4 +238,4 @@ complexity it's best to stick to the following general plan for all
 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.
\ No newline at end of file
+explicitly.