qemu-devel.nongnu.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).