[PATCH] [TEST] Add CodyingSystem and SubmittingPatches files
# HG changeset patch # User Kaitlin Rupert <karupert@us.ibm.com> # Date 1232145843 28800 # Node ID d94576542b4d6479ad04da466406c0cdb391f6e8 # Parent 684561f21975c7420cb7e15affc1eec4a8ed35ae [TEST] Add CodyingSystem and SubmittingPatches files Signed-off-by: Kaitlin Rupert <karupert@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@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>
Very Good write up. I have few ideas along with some comments on this patch(Please see inline for comments). We can improve it further including the information for "How to write a test case?" This would include information like: 1) What kind of function should be included in the libraries present in the XenKVMLib directory. 2) What should not be included in libraries present in the cimtest/lib. 3) What type of logger statements to be used for giving different messages, for ex: use logger.info("Some information") or else use logger.error("To print error") 4) Also, License information to be included in the test cases. 5) Including small description about what the test case does at the beginning will help in maintenance in the long run. 6) Commands to submit a Single patch, commands to submit a Patch Set using *"hg". T*his will make things easy for someone who is using *hg* for the first time and might encourage more new people to contribute. We can rename the CodingStyle file to "Cimtest_Howto_Doc" and then Include all the above information along with the CodingStyle in one file. We can advertise the presence of these documents at the http://wiki.libvirt.org/page/Cimtest_todo page. Any thoughts ?? Kaitlin Rupert wrote:
# HG changeset patch # User Kaitlin Rupert <karupert@us.ibm.com> # Date 1232145843 28800 # Node ID d94576542b4d6479ad04da466406c0cdb391f6e8 # Parent 684561f21975c7420cb7e15affc1eec4a8ed35ae [TEST] Add CodyingSystem and SubmittingPatches files
Signed-off-by: Kaitlin Rupert <karupert@us.ibm.com>
+ +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.
Need to include the step in case where hg export exposes something missing. Do we need to rework or just include the changes on top of the latest changes commit the changes and send the two patches? OR include the new work in the latest cimtest tree, do the missing changes and send all the changes as part of one 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. +
Including the Sign-off in each cimtest patch is also very important.
+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
libvirt-cim-bounces@redhat.com wrote on 2009-01-19 14:37:01:
Very Good write up. I have few ideas along with some comments on this patch(Please see inline for comments). We can improve it further including the information for "How to write a test case?" This would include information like: 1) What kind of function should be included in the libraries present in the XenKVMLib directory. 2) What should not be included in libraries present in the cimtest/lib. 3) What type of logger statements to be used for giving different messages, for ex: use logger.info("Some information") or else use logger.error("To print error") 4) Also, License information to be included in the test cases. 5) Including small description about what the test case does at the beginning will help in maintenance in the long run. 6) Commands to submit a Single patch, commands to submit a Patch Set using *"hg". T*his will make things easy for someone who is using *hg* for the first time and might encourage more new people to contribute. We can rename the CodingStyle file to "Cimtest_Howto_Doc" and then Include all the above information along with the CodingStyle in one file. We can advertise the presence of these documents at the http://wiki.libvirt.org/page/Cimtest_todo page. Any thoughts ??
Good. When this patch is applied, I think we should check all the libraries and test cases present to make them follow this coding style. Then we can cook up new tc.
# HG changeset patch # User Kaitlin Rupert <karupert@us.ibm.com> # Date 1232145843 28800 # Node ID d94576542b4d6479ad04da466406c0cdb391f6e8 # Parent 684561f21975c7420cb7e15affc1eec4a8ed35ae [TEST] Add CodyingSystem and SubmittingPatches files
Signed-off-by: Kaitlin Rupert <karupert@us.ibm.com>
+ +Guidelines for Submitting Patches. + + Patches should be submitted using Mercurial's
Kaitlin Rupert wrote: 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.
+ specific. Avoid just saying something like, "Various fixes to + AllocationCapabilities." Add a list of what was actually fixed, + like, "Add EnumInstanceNames support," and, "Eliminateduplicate + 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 hereand
Be 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
+ 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
+ your patch on top of it. You should still indicate
+ 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 ofthat 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
Need to include the step in case where hg export exposes something missing. Do we need to rework or just include the changes on top of the latest changes commit the changes and send the two patches? OR include the new work in the latest cimtest tree, do the missing changes and send all the changes as part of one patch. list as long tree. Now write the dependency 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. +
Including the Sign-off in each cimtest patch is also very important.
+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
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
Good. When this patch is applied, I think we should check all the libraries and test cases present to make them follow this coding style. Then we can cook up new tc.
Sure. Daisy, if you'd like to look into this, that would be great. Thanks! -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
libvirt-cim-bounces@redhat.com wrote on 2009-01-20 01:01:13:
Good. When this patch is applied, I think we should check all the libraries and test cases present to make them follow this coding style. Then we can cook up new tc.
Sure. Daisy, if you'd like to look into this, that would be great. Thanks!
I'd like to do this. But Spring Festival (Traditional Chinese New Year) is coming and I will have a vacation from Jan 21 to Feb 03. If it isn't tight on time, I will look into this when I'm back. Thanks!
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
Guo Lian Yun wrote:
libvirt-cim-bounces@redhat.com wrote on 2009-01-20 01:01:13:
Good. When this patch is applied, I think we should check all the libraries and test cases present to make them follow this coding style. Then we can cook up new tc.
Sure. Daisy, if you'd like to look into this, that would be great. Thanks!
I'd like to do this. But Spring Festival (Traditional Chinese New Year) is coming and I will have a vacation from Jan 21 to Feb 03. If it isn't tight on time, I will look into this when I'm back.
No problem - sounds like a good plan to me. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
Guo Lian Yun wrote:
libvirt-cim-bounces@redhat.com wrote on 2009-01-20 01:01:13:
Good. When this patch is applied, I think we should check all
libvirt-cim-bounces@redhat.com wrote on 2009-01-21 10:18:38: the
libraries and test cases present to make them follow this coding style. Then we can cook
up new
tc.
Sure. Daisy, if you'd like to look into this, that would be great.
Thanks!
I'd like to do this. But Spring Festival (Traditional Chinese New Year) is coming and I will have a vacation from Jan 21 to Feb 03. If it isn't tight on time, I will look into this when I'm back.
No problem - sounds like a good plan to me.
I've checked test cases present and updated them to follow below coding styles: 1) Split lines to meet 80-char width limit 2) Use commas instead of percent signs when passing parameters to logger.error() and logger.info() 3) Use percents when passing parameters to Exception() On the next, I will check and update libraries present to follow above coding styles. Thoughts? Thanks!
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
Guo Lian Yun wrote:
libvirt-cim-bounces@redhat.com wrote on 2009-01-21 10:18:38:
Guo Lian Yun wrote:
libvirt-cim-bounces@redhat.com wrote on 2009-01-20 01:01:13:
Good. When this patch is applied, I think we should check
all the
libraries and test cases present to make them follow this coding style. Then we can cook up new tc.
Sure. Daisy, if you'd like to look into this, that would be great. Thanks!
I'd like to do this. But Spring Festival (Traditional Chinese New Year) is coming and I will have a vacation from Jan 21 to Feb 03. If it isn't tight on time, I will look into this when I'm back.
No problem - sounds like a good plan to me.
I've checked test cases present and updated them to follow below coding styles:
1) Split lines to meet 80-char width limit 2) Use commas instead of percent signs when passing parameters to logger.error() and logger.info() 3) Use percents when passing parameters to Exception()
On the next, I will check and update libraries present to follow above coding styles. Thoughts?
That sounds really good.
Thanks!
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
_______________________________________________ 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
Deepti B Kalakeri wrote:
Very Good write up. I have few ideas along with some comments on this patch(Please see inline for comments). We can improve it further including the information for "How to write a test case?"
I think most of the things you have listed here can be inferred by reading the existing test cases. I know the style has changed some, so a lot of the test cases aren't in the best shape they could be. But a lot of these issues are being fixed as tests are being updated.
This would include information like: 1) What kind of function should be included in the libraries present in the XenKVMLib directory. 2) What should not be included in libraries present in the cimtest/lib.
This will change over time, so I worry that the statements will become out of date and the file will not be updated accordingly.
3) What type of logger statements to be used for giving different messages, for ex: use logger.info("Some information") or else use logger.error("To print error")
The name of the functions here should make it obvious which to use.
4) Also, License information to be included in the test cases. 5) Including small description about what the test case does at the beginning will help in maintenance in the long run.
These are good points. I can update the style guide to include this info.
6) Commands to submit a Single patch, commands to submit a Patch Set using *"hg". T*his will make things easy for someone who is using *hg* for the first time and might encourage more new people to contribute.
It's good to encourage people to contribute, but there are plenty of hg references out there that people can use. The SubmittingPatches file already mentioned that patches should be submitted using the patchbomb feature. From there, someone can reference mercurial's how to documents for more information.
We can rename the CodingStyle file to "Cimtest_Howto_Doc" and then Include all the above information along with the CodingStyle in one file.
I would like to keep the name as is since it parallels the format/structure of what's in libvirt-cim.
We can advertise the presence of these documents at the http://wiki.libvirt.org/page/Cimtest_todo page.
Not sure what you mean here.. the todo page is for keeping track of improvements/enhancements to the testsuite, as well as test cases that need to be written. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
Kaitlin Rupert wrote:
Deepti B Kalakeri wrote:
Very Good write up. I have few ideas along with some comments on this patch(Please see inline for comments). We can improve it further including the information for "How to write a test case?"
I think most of the things you have listed here can be inferred by reading the existing test cases. I know the style has changed some, so a lot of the test cases aren't in the best shape they could be. But a lot of these issues are being fixed as tests are being updated.
This would include information like: 1) What kind of function should be included in the libraries present in the XenKVMLib directory. 2) What should not be included in libraries present in the cimtest/lib.
This will change over time, so I worry that the statements will become out of date and the file will not be updated accordingly.
3) What type of logger statements to be used for giving different messages, for ex: use logger.info("Some information") or else use logger.error("To print error")
The name of the functions here should make it obvious which to use.
4) Also, License information to be included in the test cases. 5) Including small description about what the test case does at the beginning will help in maintenance in the long run.
These are good points. I can update the style guide to include this info.
6) Commands to submit a Single patch, commands to submit a Patch Set using *"hg". T*his will make things easy for someone who is using *hg* for the first time and might encourage more new people to contribute.
It's good to encourage people to contribute, but there are plenty of hg references out there that people can use.
The SubmittingPatches file already mentioned that patches should be submitted using the patchbomb feature. From there, someone can reference mercurial's how to documents for more information.
We can rename the CodingStyle file to "Cimtest_Howto_Doc" and then Include all the above information along with the CodingStyle in one file.
I would like to keep the name as is since it parallels the format/structure of what's in libvirt-cim.
We can advertise the presence of these documents at the http://wiki.libvirt.org/page/Cimtest_todo page.
Not sure what you mean here.. the todo page is for keeping track of improvements/enhancements to the testsuite, as well as test cases that need to be written.
I meant to refer the presence of the docs that you have written in the To do page, for first timer to give a pointer to these docs which might solve some of their FAQ's immediately. I understand that its standard to have the docs directory is obvious, but still it might help someone. -- Thanks and Regards, Deepti B. Kalakeri IBM Linux Technology Center deeptik@linux.vnet.ibm.com
participants (3)
-
Deepti B Kalakeri -
Guo Lian Yun -
Kaitlin Rupert