[libvirt] [PATCH]show the autostart status when displaya'virsh dominfo'.

[Richard W.M. Jones]

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
-------------- next part --------------
? 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.