General tips for contributing patches

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

diff --git a/ChangeLog b/ChangeLog
index 92101136cca9c543e33d2deda06dd9bee5a383f3..6ccfe02e97fa7103c28718392a457a097c9c6e14 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+Mon Jun  2 12:52:00 BST 2008 Richard W.M. Jones <rjones@redhat.com>
+
+       General tips for contributing patches
+       * HACKING: Added section "general tips for contributing patches"
+       to this file.
+
 Thu May 29 16:43:00 EST 2008 Daniel P. Berrange <berrange@redhat.com>
 
        * autobuild.sh: Only run converage tests if lcov is installed

diff --git a/HACKING b/HACKING
index c4ec6ca03643c701c8bb04190da6463d2a9ca856..aabdcc2d96d0afbcff8760a33f057c664d5ef740 100644 (file)
--- 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.