From: Markus Armbruster <armbru@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] MAINTAINERS: Add an entry for qemu-options* files in main directory
Date: Wed, 13 Jun 2018 08:23:25 +0200 [thread overview]
Message-ID: <87d0wvkxwi.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <dcd08712-9dbd-eeda-7040-40b1afb14429@redhat.com> (Paolo Bonzini's message of "Tue, 12 Jun 2018 17:04:07 +0200")
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 12/06/2018 12:46, Thomas Huth wrote:
>> Markus Armbruster <armbru@redhat.com> writes:
>>> CLI is like QMP in that there's infrastructure, interface and
>>> implementation.
>>>
>>> QMP infrastructure is MAINTAINERS sections QMP and QAPI. These are
>>> proper subsystems, with clear boundaries. Its maintainers get copied on
>>> relatively few patches.
>>>
>>> QMP infrastructure doesn't own the actual commands[1], subsystems do.
>>> For instance, the block subsystem owns commands dealing with block
>>> devices.
>>>
>>> The QMP interface is specified in the QAPI schema. Again, QMP
>>> infrastructure doesn't own it, subsystems do. However, to maintain some
>>> measure of cohesion, we co-maintain the interface: MAINTAINERS section
>>> QAPI schema covers the complete schema, and subsystems cover individual
>>> modules of the schema[2].
>>>
>>> I think a similar arrangement make sense for CLI. We'll get it for free
>>> with CLI QAPIfication, but that'll take time.
>>>
>>> Your patch does what is possible with a monolithic interface definition:
>>> it dumps it all on one maintainer: me. I'm struggling to keep up with
>>> the QAPI schema, I'm not sure I can take more.
>>>
>>> Note that "Command line option argument parsing" is phrased carefully:
>>> it's not "CLI", not even "CLI parsing". qemu-options* does not fit
>>> there. Two solutions: widen the section so it fits better, create a new
>>> section. The latter would be closer to how we do QMP.
>>>
>>> What do you think?
>> Both ideas sound fine to me. What about adding a new section called
>> "Generic command line options"? I hope that the word "generic" then
>> makes it clear that this entry is primarily thought for generic options
>> - subsystem specific options can and should still go through the
>> subsystem trees instead.
How well would that work in practice? get_maintainers.pl can't tell
apart "generic" from "specific to subsystem S"...
For QMP, get_maintainers.pl identifies the parts. Subsystem-specific
parts are co-maintained by subsystem and QAPI schema maintainers, and
expected to go through the subsystem tree. The "whatever remains" part
is maintained just by QAPI schema maintainers, and goes through various
trees in practice. Note "whatever remains" > "generic"; it's a bit of a
dumping ground right now.
>> Do you think you could still be available as (co-)maintainer of that new
>> section? If not, who are going to be the maintainers of that new
>> section? Paolo? Eric? Daniel? ...?
>
> Well, currently it's going through me. I'd add vl.c too, by the way.
vl.c has much more than just CLI parsing. It's pushing 4kSLOC...
Splitting it up would be nice. As long as it's not, I guess the
pragmatic solution is to have multiple MAINTAINERS sections claim it:
existing "Main loop", proposed "CLI", ...
Me helping to maintain CLI in addition to some of its infrastructure
would make plenty of sense if my day had 32 hours or so. Ask Marc-André
what he thinks of me taking on *more* maintenance %-}
next prev parent reply other threads:[~2018-06-13 6:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-09 5:20 [Qemu-devel] [PATCH] MAINTAINERS: Add an entry for qemu-options* files in main directory Thomas Huth
2018-06-11 15:53 ` Markus Armbruster
2018-06-12 10:46 ` Thomas Huth
2018-06-12 15:04 ` Paolo Bonzini
2018-06-13 6:23 ` Markus Armbruster [this message]
2018-06-13 12:37 ` 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=87d0wvkxwi.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@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.