From: Harsh Bora <harsh@linux.vnet.ibm.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Brad Hards <bradh@frogmouth.net>,
Stefan Hajnoczi <stefanha@gmail.com>,
"M. Mohan Kumar" <mohan@in.ibm.com>,
qemu-devel@nongnu.org, Sripathi Kodi <sripathik@in.ibm.com>,
"Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>,
"Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] KVM call agenda for April 05
Date: Thu, 07 Apr 2011 15:08:34 +0530 [thread overview]
Message-ID: <4D9D861A.8080106@linux.vnet.ibm.com> (raw)
In-Reply-To: <4D9B7BF5.9080509@codemonkey.ws>
On 04/06/2011 02:00 AM, Anthony Liguori wrote:
> On 04/05/2011 03:25 PM, Peter Maydell wrote:
>> On 5 April 2011 14:14, Stefan Hajnoczi<stefanha@gmail.com> wrote:
>>> This stems from the fact that development is centered around the
>>> mailing list. Some folks have put technical documentation on the wiki
>>> but a lot simply happens on the mailing list.
>>> I'm unsure how we can sustainably keep the wiki up-to-date on detailed
>>> code internals knowledge. Any suggestions, any examples of projects
>>> doing this successfully?
Well, Libvirt community does follow the practice of requiring the patch
submitter to provide enough documentation within docs/ folder or in the
patch itself. The commiter ensures that the docs/ are updated with the
patch desc if docs/ are not updated as a part of the patch.
See http://libvirt.org/hacking.html#patches
>> Another approach would be to try to increase the use of docs/
>> for technical code internals information. The advantage would be
>> that we could choose to require docs/ updates for design changes
>> in order for a code change to pass patch review; the disadvantage
>> would be that it's inevitably more of a pain to update.
Yes, Its better to have code and docs being updated together with the
patches coming in, however, it will become more difficult to follow this
practice if it is not followed regularly, for. eg, if patch A doesnt
updates the docs as required, and a patch B which is based on Patch A
wants to update docs, it needs to get the required docuemntation for
patch A first before putting documentation for the patch B itself.
>
> We've been unofficially doing that for a lot of recent stuff.
>
> I don't know that that really helps with the problem of keeping it up to
> date though.
Well, as we have been doing it unofficially for recent stuff, it will be
better to have it officially now :). It shall definitely help, as it
gives an opportunity to even update an obsolete piece of info as
compared to having no docs to update.
As they say, something is better than nothing !
regards,
Harsh
>
> Regards,
>
> Anthony Liguori
>
>> -- PMM
>>
>
>
>
next prev parent reply other threads:[~2011-04-07 9:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-04 19:22 KVM call agenda for April 05 Juan Quintela
2011-04-04 19:22 ` [Qemu-devel] " Juan Quintela
2011-04-04 19:59 ` Anthony Liguori
2011-04-04 19:59 ` Anthony Liguori
2011-04-04 20:38 ` Lucas Meneghel Rodrigues
2011-04-04 20:38 ` Lucas Meneghel Rodrigues
2011-04-05 6:01 ` Brad Hards
2011-04-05 8:27 ` Stefan Hajnoczi
2011-04-05 8:29 ` Alexander Graf
2011-04-05 8:42 ` Stefan Hajnoczi
2011-04-05 9:44 ` Brad Hards
2011-04-05 9:50 ` Alexander Graf
2011-04-05 10:53 ` Stefan Hajnoczi
2011-04-05 12:04 ` Brad Hards
2011-04-05 12:21 ` Brad Hards
2011-04-05 13:14 ` Stefan Hajnoczi
2011-04-05 20:25 ` Peter Maydell
2011-04-05 20:30 ` Anthony Liguori
2011-04-07 9:38 ` Harsh Bora [this message]
2011-04-05 9:36 ` Alon Levy
2011-04-05 9:36 ` Alon Levy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D9D861A.8080106@linux.vnet.ibm.com \
--to=harsh@linux.vnet.ibm.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=anthony@codemonkey.ws \
--cc=bradh@frogmouth.net \
--cc=jvrao@linux.vnet.ibm.com \
--cc=mohan@in.ibm.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=sripathik@in.ibm.com \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.