From: Markus Armbruster <armbru@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>,
qemu-block@nongnu.org, qemu-devel@nongnu.org,
Max Reitz <mreitz@redhat.com>, Cleber Rosa <crosa@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC 2/3] pxtool: Add new qemu-img command info generation tool
Date: Fri, 12 Apr 2019 10:04:18 +0200 [thread overview]
Message-ID: <8736mnr6nx.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <01d9a861-cc2a-38a0-c471-cfefa9dbbf3b@redhat.com> (John Snow's message of "Thu, 11 Apr 2019 16:02:24 -0400")
John Snow <jsnow@redhat.com> writes:
> On 4/11/19 2:22 AM, Markus Armbruster wrote:
>> John Snow <jsnow@redhat.com> writes:
[...]
>>> I suspect that work *IS* something that might brush up against / should
>>> use (or extend) QAPI code.
>>
>> Seems likely.
>>
>>> Then, I'd like to find a way to split qemu-img.texi into sub-command
>>> files and find a way to source the same "informative text" for both:
>>>
>>> (1) The texi output, as per usual, and
>>> (2) qemu-img subcommand --help
>>>
>>> such that --help, when passed as an argument to the subcommand, prints
>>> out help only relevant to the subcommand instead, e.g.
>>>
>>> `qemu-img check --help`
>>>
>>> might print the "common options" section only as it relates to commands
>>> actually used by the check command, then prints the check section of the
>>> texi as formatted for terminals.
>>>
>>> This way, we can have manpages, html pages, and interactive help text
>>> all derived from the same semi-automated sources, always up to date and
>>> much easier to read/discover/parse by human eyeballs.
>>>
>>> That's what I'd like to accomplish, ultimately.
>>>
>>> For now, I think this RFC set is not harmful and won't bother anybody.
>>> It's definitely not worse than what we have now, fragility of removing
>>> @var{} tokens and all.
>>
>> Makes sense. I just hope we can avoid duplicating work.
>>
>
> I'm not going to proceed any further than this RFC without us having a
> meeting to discuss the work. I'm willing to learn QAPI and do it a bit,
> it's a thread I'd rather like to pull, but I don't want to duplicate any
> work, no.
I think the path forward depends on just how itchy the thing is for you.
I do want to resume the work on CLI QAPIfication. Whenever I think my
queue is about to reach a state where I can ignore y'all for the
uninterrupted time the CLI project needs, something else lands in my
queue. Right now, Kevin wants the next QAPI project to be "features
flags", and he has v1 patches to back this up[*]. I have additional
uses for feature flags in mind, which I expect to require more patches.
> If that involves me reviewing patches when the tree opens, please CC me,
> and let's have a chat!
Yes, let's talk.
> In the meantime, what are your thoughts on patches 2-3 here?
I'll try to have a closer look.
[*] Which I still have to review, but when my queue goes out of control,
I enter batch mode for better throughput, sacrificing latency.
next prev parent reply other threads:[~2019-04-12 8:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-10 1:24 [Qemu-devel] [PATCH RFC 0/3] qemu-img: remove command documentation duplication John Snow
2019-04-10 1:24 ` John Snow
2019-04-10 1:24 ` [Qemu-devel] [PATCH RFC 1/3] qemu-img: fix .hx and .texi disparity John Snow
2019-04-10 1:24 ` John Snow
2019-04-10 1:24 ` [Qemu-devel] [PATCH RFC 2/3] pxtool: Add new qemu-img command info generation tool John Snow
2019-04-10 1:24 ` John Snow
2019-04-10 5:54 ` Markus Armbruster
2019-04-10 5:54 ` Markus Armbruster
2019-04-10 17:55 ` John Snow
2019-04-10 17:55 ` John Snow
2019-04-11 6:22 ` Markus Armbruster
2019-04-11 6:22 ` Markus Armbruster
2019-04-11 20:02 ` John Snow
2019-04-11 20:02 ` John Snow
2019-04-12 8:04 ` Markus Armbruster [this message]
2019-04-12 8:04 ` Markus Armbruster
2019-04-10 1:24 ` [Qemu-devel] [PATCH RFC 3/3] qemu-img.texi: use macros for command summaries John Snow
2019-04-10 1:24 ` John Snow
2019-06-26 18:03 ` [Qemu-devel] [PATCH RFC 0/3] qemu-img: remove command documentation duplication Max Reitz
2019-06-26 18:07 ` John Snow
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=8736mnr6nx.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=crosa@redhat.com \
--cc=ehabkost@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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).