All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] Sphinx for QEMU docs? (and a doc-comment format question)
Date: Mon, 7 Nov 2016 13:41:55 +0000	[thread overview]
Message-ID: <20161107134155.GK6316@redhat.com> (raw)
In-Reply-To: <20161107133045.GM5036@stefanha-x1.localdomain>

On Mon, Nov 07, 2016 at 01:30:45PM +0000, Stefan Hajnoczi wrote:
> On Sat, Nov 05, 2016 at 06:42:23PM +0000, Peter Maydell wrote:
> > In particular I think we could:
> >  * set up a framework for our in-tree docs/ which gives us a
> >    place to put new docs (both for-users and for-developers) --
> >    I think having someplace to put things will reduce the barrier
> >    to people writing useful new docs
> >  * gradually convert the existing docs to rst
> >  * use the sphinx extension features to pull in the doc-comments
> >    we have been fairly consistently writing over the last few years
> >    (for instance a converted version of docs/memory.txt could pull
> >    in doc comments from memory.h; or we can just write simple
> >    wrapper files like a "Bitmap operations" document that
> >    displays the doc comments from bitops.h)
> 
> You are suggesting Sphinx for two different purposes:
> 
> 1. Formatting docs/ in HTML, PDF, etc.
> 
> 2. API documentation from doc comments.
> 
> It's a good idea for #1 since we can then publish automated builds of
> the docs.  They will be easy to view and link to in a web browser.
> 
> I'm not a fan of #2.  QEMU is not a C library that people develop
> against and our APIs are not stable.  There is no incentive for pretty
> doc comments.  It might be cool to set it up once but things will
> deterioate again quickly because we don't actually need external API
> docs.

For shared internal infrastructure code I very much disagree. If I'm
writing something (like a new block driver), I'm relying on a bunch
of existing code that I'm calling. Some of the methods I'm consuming
may be in a library like GLib, other methods may be QEMU internal
infrastructure (like util/*, io/*, cryto/*). Regardless of whether
those methods are internal or from a library, the API docs are very
important / valuable in ensuring I'm understanding the required usage
contract of the method. The lack of API docs for the QEMU block layer
was a major cause of pain for me when writing the LUKS driver.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

  reply	other threads:[~2016-11-07 13:42 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-05 18:42 [Qemu-devel] Sphinx for QEMU docs? (and a doc-comment format question) Peter Maydell
2016-11-07  9:35 ` Daniel P. Berrange
2016-11-07 13:30 ` Stefan Hajnoczi
2016-11-07 13:41   ` Daniel P. Berrange [this message]
2016-11-07 13:49   ` Peter Maydell
2016-11-07 22:52   ` John Snow
2016-11-08 16:20     ` Stefan Hajnoczi
2016-11-08 16:24       ` John Snow
2016-11-09 11:32         ` Stefan Hajnoczi
2016-11-10  3:39           ` Fam Zheng
2016-11-10  9:55             ` Stefan Hajnoczi
2016-11-10 10:08             ` Paolo Bonzini
2016-11-10 10:55               ` Daniel P. Berrange
2016-11-08 23:56   ` Paolo Bonzini
2016-11-07 15:03 ` Peter Maydell
2016-11-07 17:04   ` Paolo Bonzini
2016-11-07 17:20     ` Peter Maydell
2016-11-07 17:50       ` Paolo Bonzini
2016-11-07 18:23         ` Peter Maydell
2016-11-07 19:43           ` Paolo Bonzini
2016-11-07 20:36             ` Peter Maydell
2016-11-08  5:02   ` Emilio G. Cota
2017-01-05 16:47   ` Paolo Bonzini

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=20161107134155.GK6316@redhat.com \
    --to=berrange@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=stefanha@redhat.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.