From: Kevin Wolf <kwolf@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Daniel P. Berrangé" <berrange@redhat.com>,
qemu-block@nongnu.org, "Kashyap Chamarthy" <kchamart@redhat.com>,
afrosi@redhat.com, "Philippe Mathieu-Daudé" <philmd@redhat.com>,
qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>
Subject: Re: [PATCH 1/4] docs: lift block-core.json rST header into parents
Date: Tue, 8 Sep 2020 16:23:08 +0200 [thread overview]
Message-ID: <20200908142308.GD8175@linux.fritz.box> (raw)
In-Reply-To: <f5de1038-5bf3-8bd4-d664-45d6f201ae9b@redhat.com>
Am 08.09.2020 um 14:03 hat Laszlo Ersek geschrieben:
> Hi Stefan,
>
> On 09/08/20 11:31, Stefan Hajnoczi wrote:
> > block-core.json is included from several places. It has no way of
> > knowing what header level (h1, h2, ...) is appropriate. Sphinx reports
> > errors when it encounters an h2 header where it expects an h1 header.
> > This issue prevents the next patch from generating documentation for
> > qemu-storage-daemon QMP commands.
> >
> > Move the header into parents so that the correct header level can be
> > used. Note that transaction.json is not updated since it doesn't seem to
> > need a header.
> >
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > ---
> > docs/interop/firmware.json | 4 ++++
> > qapi/block-core.json | 4 ----
> > qapi/block.json | 1 +
> > 3 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/docs/interop/firmware.json b/docs/interop/firmware.json
> > index 989f10b626..48af327f98 100644
> > --- a/docs/interop/firmware.json
> > +++ b/docs/interop/firmware.json
> > @@ -15,6 +15,10 @@
> > ##
> >
> > { 'include' : 'machine.json' }
> > +
> > +##
> > +# == Block devices
> > +##
> > { 'include' : 'block-core.json' }
> >
> > ##
>
> I think "docs/interop/firmware.json" deserves the same treatment as
> "transaction.json".
>
> It's been a long time since I last looked at a rendered view of
> "docs/interop/firmware.json", but it only includes "block-core.json" so
> it can refer to some block-related types (@BlockdevDriver seems like the
> main, or only, one).
>
> I wouldn't expect the rendered view of "firmware.json" to have a section
> header saying "Block devices".
>
> I think it should be fine to drop this hunk (and my CC along with it ;))
I think this is actually a more general problem with the way we generate
the documentation. For example, the "Background jobs" documentation ends
up under "Block Devices" just because qapi-schema.json includes
block-core.json before job.json and block-core.json includes job.json to
be able to access some types.
Maybe we should always look for the least nested include directive to
figure out where the documentation should be placed. Then things
directly referenced by qapi-schema.json would always be on the top
level.
Possibly we would then want to remove some includes from
qapi-schema.json and include them only from some other file to group
documentation sections that actually make sense to be grouped together.
Kevin
next prev parent reply other threads:[~2020-09-08 14:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-08 9:31 [PATCH 0/4] docs: add qemu-storage-daemon documentation Stefan Hajnoczi
2020-09-08 9:31 ` [PATCH 1/4] docs: lift block-core.json rST header into parents Stefan Hajnoczi
2020-09-08 12:03 ` Laszlo Ersek
2020-09-08 14:23 ` Kevin Wolf [this message]
2020-09-09 7:38 ` Markus Armbruster
2020-09-09 7:52 ` Kevin Wolf
2020-09-09 12:10 ` Markus Armbruster
2020-09-09 13:22 ` Kevin Wolf
2020-09-09 15:28 ` Markus Armbruster
2020-09-09 15:38 ` Kevin Wolf
2020-09-10 5:18 ` Markus Armbruster
2020-09-10 9:18 ` Kevin Wolf
2020-09-09 8:06 ` Kevin Wolf
2020-09-08 9:31 ` [PATCH 2/4] docs: generate qemu-storage-daemon-qmp-ref(7) man page Stefan Hajnoczi
2020-09-08 9:31 ` [PATCH 3/4] docs: add qemu-storage-daemon(1) " Stefan Hajnoczi
2020-09-08 11:42 ` Kashyap Chamarthy
2020-09-08 14:33 ` Kevin Wolf
2020-09-09 8:59 ` Stefan Hajnoczi
2020-09-08 9:31 ` [PATCH 4/4] MAINTAINERS: add Kevin Wolf as storage daemon maintainer Stefan Hajnoczi
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=20200908142308.GD8175@linux.fritz.box \
--to=kwolf@redhat.com \
--cc=afrosi@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=kchamart@redhat.com \
--cc=lersek@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--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).