[Libvirt-cim] [PATCH] [TEST] Add CodyingSystem and SubmittingPatches files

Kaitlin Rupert kaitlin at linux.vnet.ibm.com
Fri Jan 16 22:44:50 UTC 2009


# HG changeset patch
# User Kaitlin Rupert <karupert at us.ibm.com>
# Date 1232145843 28800
# Node ID d94576542b4d6479ad04da466406c0cdb391f6e8
# Parent  684561f21975c7420cb7e15affc1eec4a8ed35ae
[TEST] Add CodyingSystem and SubmittingPatches files

Signed-off-by: Kaitlin Rupert <karupert at us.ibm.com>

diff -r 684561f21975 -r d94576542b4d doc/CodingStyle
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/CodingStyle	Fri Jan 16 14:44:03 2009 -0800
@@ -0,0 +1,41 @@
+
+The CodingStyle for cimtest (and libcmpiutil) mostly mirrors that of 
+libvirt-cim but with the following "clarifications":
+
+- Four-space indents
+
+- 80-char width limit.  Break long function calls by:
+    a) putting *every* parameter of the call on its own line
+        -or-
+    b) putting as many params in a line as will fit in the 80-char limit; 
+       overflow params are placed on the subsequent line
+
+- Split lines should aligned like the following:
+
+        VirtCIM.__init__(self, 'Xen', test_dom, disk, disk_file_path,
+                         ntype, net_name, mac, vcpus, mem, mem_allocunits,
+                         emu_type)
+
+- Identifiers should be named with underbars_and_lowercase.
+
+- When passing parameters to logger.error() and logger.info(), use
+  commas:
+
+       logger.error("%s is not a valid network type", net_type)
+
+  Not percent signs:
+
+       logger.error('Got CIM error %s with return code %s' % (desc, rc))
+
+- When passing parameters to Exception(), use percents:
+
+       raise Exception("Unable to define %s" % test_dom)
+  
+  Not commas:
+
+       raise Exception("Unable to define %s", test_dom)
+
+- Except for special cases, import the needed functions from a module.  Do not
+  import the entire module:
+
+       from XenKvmLib.classes import virt_types 
diff -r 684561f21975 -r d94576542b4d doc/SubmittingPatches
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/SubmittingPatches	Fri Jan 16 14:44:03 2009 -0800
@@ -0,0 +1,117 @@
+To submit patches to libvirt-cim, you must follow the DCO process, outlined
+below.
+
+Developer's Certificate of Origin 1.1
+        By making a contribution to this project, I certify that:
+
+        (a) The contribution was created in whole or in part by me and I
+            have the right to submit it under the open source license
+            indicated in the file; or
+
+        (b) The contribution is based upon previous work that, to the best
+            of my knowledge, is covered under an appropriate open source
+            license and I have the right under that license to submit that
+            work with modifications, whether created in whole or in part
+            by me, under the same open source license (unless I am
+            permitted to submit under a different license), as indicated
+            in the file; or
+
+        (c) The contribution was provided directly to me by some other
+            person who certified (a), (b) or (c) and I have not modified
+            it.
+
+        (d) I understand and agree that this project and the contribution
+            are public and that a record of the contribution (including all
+            personal information I submit with it, including my sign-off) is
+            maintained indefinitely and may be redistributed consistent with
+            this project or the open source license(s) involved.
+
+then you just add a line saying
+
+        Signed-off-by: Random J Developer <random at developer.example.org>
+
+using your real name (sorry, no pseudonyms or anonymous contributions.)
+
+
+
+Guidelines for Submitting Patches.
+
+           Patches should be submitted using Mercurial's patchbomb extension, 
+           and we recommend using the queues extension as well.  On top of that, 
+           we have some guidelines you should follow when submitting patches.  
+           This makes reviewing patches easier, which in turns improves the 
+           chances of your patch being accepted in a timely fashion.
+
+Single Patches:
+
+       (a) When you add a patch to the queue you have an idea of where you're
+           going with it, and the commit message should reflect that.  Be
+           specific.  Avoid  just saying something like, "Various fixes to
+           AllocationCapabilities."  Add a list of what was actually fixed, 
+           like, "Add EnumInstanceNames support," and, "Eliminate duplicate 
+           instances."  
+
+       (b) The first line of your commit message will be the subject of the 
+           patch email when you send it out, so write it like a subject.  Keep 
+           it short and to the point, then start a new line and feel free to be 
+           as verbose as you need to be.  The entire commit message will be 
+           included in the patch.
+
+       (c) Stay on task with a patch.  If you notice other problems while you
+           are working on patch, and they are not most definitely specific to 
+           your patch, they should be another patch.  The same goes for 
+           nitpicking.  While it might be only a line or two here and there 
+           that is off track, this is actually one of the easiest ways to make 
+           a patch difficult to review.  All the trivial changes hide what is 
+           really going on.  Make the unrelated changes a new patch or don't 
+           make them at all.
+
+       (d) Before you email, export.  If you have a patch called "alloc_fixes", 
+           which would be emailed with "hg email alloc_fixes", you should first 
+           run "hg export alloc_fixes".  This lets you review your patch.  Does 
+           it have any typos in the comments?  Did you accidentally include an 
+           irrelevant change?  Is your commit message still accurate and useful?
+           This is the single biggest step in ensuring you have a good patch.
+
+       (e) If your patch needs to be reworked and resent, prepend a "version 
+           number" to the first line of the commit message.  For example, "Add 
+           EnumInstance to RASD," becomes "(#2) Add EnumInstance to RASD."  
+           This helps mail readers thread discussions correctly and helps
+           maintainers know they are applying the right version of your patch.  
+           At the end of the commit message, explain what is different from one 
+           version to the next.  Nobody likes having to diff a diff.  
+
+       (f) If your patch depends on a patch that exists on the mailing list but 
+           not in the tree, it is okay to send your patch to the list as long 
+           as your commit message mentions the dependency.  It is also a good 
+           idea to import the patch into your tree before you make your patch.
+           For example, a new patch called "cu_statusf API change" is on the 
+           list, and your patch needs the new API.  Save the email (no need to 
+           trim headers) as api_change.eml, then do "hg qimport api_change.eml" 
+           and "hg qpush" so that the patch is applied to your tree.  Now write 
+           your patch on top of it.  You should still indicate the dependency 
+           in your commit message.
+
+
+Patchsets:
+
+       (a) When you send a group of patches, Mercurial's email extension will
+           create a "header" email.  Make the subject and body of that email
+           meaningful, so we know how the patches relate.  It's easy to say, 
+           "Each patch has a commit message, it's obvious how they work 
+           together," but the rest of the list usually won't agree with that.  
+           If the commit messages for each patch are good, you shouldn't need 
+           more than a sentence or two to tie them all together, but you do 
+           need it.
+
+       (b) If any of your patches are rejected and you rework them, resend the
+           entire set.  This prevents things like, "So use patch 1 of 4 from 
+           the set I sent yesterday, 2 and 3 of 4 from the patch I sent an hour 
+           later, and patch 4 of 4 from today."
+
+       (c) If you resend a patchset, apply part (e) of the Single Patches 
+           guidelines to your "Patch [0 of 3]" header email, for all the same 
+           reasons.
+
+Questions/Comments on the Guidelines should be directed to:
+ Kaitlin Rupert<kaitlin at linux.vnet.ibm.com>




More information about the Libvirt-cim mailing list