[Libvirt-cim] [PATCH] [TEST] #2 Add CodyingSystem and SubmittingPatches files
Deepti B Kalakeri
deeptik at linux.vnet.ibm.com
Mon Jan 19 17:28:50 UTC 2009
+1
Kaitlin Rupert wrote:
> # HG changeset patch
> # User Kaitlin Rupert <karupert at 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 at 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 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>
>
> _______________________________________________
> Libvirt-cim mailing list
> Libvirt-cim at redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-cim
>
--
Thanks and Regards,
Deepti B. Kalakeri
IBM Linux Technology Center
deeptik at linux.vnet.ibm.com
More information about the Libvirt-cim
mailing list