All of lore.kernel.org
 help / color / mirror / Atom feed
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
>>
>
>
>

  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.