From 4a9ebf7da791f4fe5e3c94ac9ba6c987016ab32f Mon Sep 17 00:00:00 2001 From: "Richard W.M. Jones" Date: Mon, 2 Jun 2008 11:53:23 +0000 Subject: [PATCH] General tips for contributing patches * HACKING: Added section "general tips for contributing patches" to this file. --- ChangeLog | 6 ++++++ HACKING | 42 +++++++++++++++++++++++++++++++++++++++++- 2 files changed, 47 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 92101136cc..6ccfe02e97 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +Mon Jun 2 12:52:00 BST 2008 Richard W.M. Jones + + 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 * autobuild.sh: Only run converage tests if lcov is installed diff --git a/HACKING b/HACKING index c4ec6ca036..aabdcc2d96 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.