On Wed, May 28, 2008 at 02:18:50PM +0100, Daniel P. Berrange wrote: > On Wed, May 28, 2008 at 11:21:05AM +0900, Atsushi SAKAI wrote: > > Hi, Rich and Dan > > > > Thank you for fixing this. > > I think it should be noted about submitting patch on HACKING file or others. > > How do you think? > > (like make check; make syntax-check; make tests) > > Yes, basically the three things you should run before committing patches > are > > make check > make syntax-check > make valgrind (in the tests/ sub-dir) > > The latter checks for memory leaks. > > Of course I myself forget this often - which is why we have the automated > nightly builds, so we never miss the problem for longer than a day Suggested patch to HACKING file. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
? scripts/Makefile ? scripts/Makefile.in Index: HACKING =================================================================== RCS file: /data/cvs/libvirt/HACKING,v retrieving revision 1.3 diff -u -p -r1.3 HACKING --- HACKING 23 May 2008 08:24:41 -0000 1.3 +++ HACKING 2 Jun 2008 09:42:09 -0000 @@ -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 fol 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.
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list