[PATCH] [TEST] #2 Add CodyingSystem and SubmittingPatches files
# HG changeset patch # User Kaitlin Rupert <karupert@us.ibm.com> # Date 1232385019 28800 # Node ID 043761891eecf7e5f565a0ca74749494d878fd80 # Parent a5a4d35749d1d9ed8604ea4879e12828c7f5b169 [TEST] #2 Add CodyingSystem and SubmittingPatches files Updates: -Added information about license header and comments Signed-off-by: Kaitlin Rupert <karupert@us.ibm.com> diff -r a5a4d35749d1 -r 043761891eec doc/CodingStyle --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/CodingStyle Mon Jan 19 09:10:19 2009 -0800 @@ -0,0 +1,47 @@ + +The CodingStyle for cimtest (and libcmpiutil) mostly mirrors that of +libvirt-cim but with the following "clarifications": + +- Each new file needs to have be appropriate license header (see existing test + cases) + +- Test cases should also include a short desciption that describes the purpose + of the test. + +- 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 a5a4d35749d1 -r 043761891eec doc/SubmittingPatches --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/SubmittingPatches Mon Jan 19 09:10:19 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@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@linux.vnet.ibm.com>
+1 Kaitlin Rupert wrote:
# HG changeset patch # User Kaitlin Rupert <karupert@us.ibm.com> # Date 1232385019 28800 # Node ID 043761891eecf7e5f565a0ca74749494d878fd80 # Parent a5a4d35749d1d9ed8604ea4879e12828c7f5b169 [TEST] #2 Add CodyingSystem and SubmittingPatches files
Updates: -Added information about license header and comments
Signed-off-by: Kaitlin Rupert <karupert@us.ibm.com>
diff -r a5a4d35749d1 -r 043761891eec doc/CodingStyle --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/CodingStyle Mon Jan 19 09:10:19 2009 -0800 @@ -0,0 +1,47 @@ + +The CodingStyle for cimtest (and libcmpiutil) mostly mirrors that of +libvirt-cim but with the following "clarifications": + +- Each new file needs to have be appropriate license header (see existing test + cases) + +- Test cases should also include a short desciption that describes the purpose + of the test. + +- 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 a5a4d35749d1 -r 043761891eec doc/SubmittingPatches --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/SubmittingPatches Mon Jan 19 09:10:19 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@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@linux.vnet.ibm.com>
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
-- Thanks and Regards, Deepti B. Kalakeri IBM Linux Technology Center deeptik@linux.vnet.ibm.com
participants (2)
-
Deepti B Kalakeri -
Kaitlin Rupert