QEMU-Riscv Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Philippe Mathieu-Daudé" <philmd@oss.qualcomm.com>,
	qemu-devel@nongnu.org, alistair23@gmail.com,
	qemu-riscv@nongnu.org, bin.meng@processmission.com,
	mzamazal@redhat.com, sgarzare@redhat.com
Subject: Re: [PATCH 2/2] MAINTAINERS: Mark "vhost-user-scmi" orphaned
Date: Wed, 15 Jul 2026 08:16:01 +0200	[thread overview]
Message-ID: <87ik6gixr2.fsf@pond.sub.org> (raw)
In-Reply-To: <20260714151629-mutt-send-email-mst@kernel.org> (Michael S. Tsirkin's message of "Tue, 14 Jul 2026 15:23:13 -0400")

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Mon, Jul 13, 2026 at 10:17:07AM +0200, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> writes:
>> 
>> > On 13/7/26 08:52, Michael S. Tsirkin wrote:
>> >> On Mon, Jul 13, 2026 at 08:13:38AM +0200, Philippe Mathieu-Daudé wrote:
>> >>> On 11/7/26 10:00, Michael S. Tsirkin wrote:
>> >>>> On Fri, Jul 10, 2026 at 01:43:05PM +0200, Markus Armbruster wrote:
>> >>>>> Commit a5dab090e1 (hw/virtio: Add boilerplate for vhost-user-scmi
>> >>>>> device, 2023-06-28) added the section with S: Supported, but no M:.
>> >>>>> This makes no sense.  Downgrade to S: Orphan.
>> >>>>>
>> >>>>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>> >>>>
>> >>>>
>> >>>> No, this makes sense. The reason this section was added is so that Milan can
>> >>>> get copied on vhost-user-scmi but not other virtio stuff:
>> >>>>
>> >>>> ./scripts/get_maintainer.pl -f hw/virtio/vhost-user-scmi.c
>> >>>> Milan Zamazal <mzamazal@redhat.com> (reviewer:vhost-user-scmi)
>> >>>> "Michael S. Tsirkin" <mst@redhat.com> (supporter:vhost)
>> >>>> Stefano Garzarella <sgarzare@redhat.com> (reviewer:vhost)
>> >>>> qemu-devel@nongnu.org (open list:All patches CC here)
>> >>>>
>> >>>> Pls drop this patch.
>> >>>>
>> >>>>> ---
>> >>>>>    MAINTAINERS | 2 +-
>> >>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>> >>>>>
>> >>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>> >>>>> index aa2df9cbe3..4d558ddee9 100644
>> >>>>> --- a/MAINTAINERS
>> >>>>> +++ b/MAINTAINERS
>> >>>>> @@ -2622,7 +2622,7 @@ F: include/hw/virtio/vhost-user-snd.h
>> >>>>>    vhost-user-scmi
>> >>>
>> >>> So what we want is to add here:
>> >>>
>> >>>    M: Michael S. Tsirkin <mst@redhat.com>
>> >>>    R: Stefano Garzarella <sgarzare@redhat.com>
>> >>
>> >> But these files already get M from the match against hw/virtio/ -
>> >> what am I missing?
>> >
>> > Yeah, just trying to make Markus script happy ;)
>> 
>> Appreciate the kindness!
>> 
>> In decreasing importance:
>> 
>> 1. Correct get_maintainers.pl output
>
> Is anything wrong with it?

No, it looks good to me.

>> 2. Legible MAINTAINERS
>
> We can always come up with a new rule for such cases,
> where we have a reviewer just for some specific files
> in a project, but the supporters are from the bigger
> project.
>
> How about we drop S: completely in such cases?

Could that be differently confusing?  Honest question!

1. Correct get_maintainers.pl output

   Appears to be fine.  As far as I can tell, it accumulates S: for all
   matching sections.  A matching section without S: should be harmless
   as long as another matching section provides one.

   By the way, this is another reason why my patch was bad.  The S:
   Orphan gets accumulated, and can lead to problematic output, e.g.

    $ scripts/get_maintainer.pl --status -f hw/virtio/vhost-user-scmi.c 
    Milan Zamazal <mzamazal@redhat.com> (reviewer:vhost-user-scmi)
    "Michael S. Tsirkin" <mst@redhat.com> (supporter:vhost)
    Stefano Garzarella <sgarzare@redhat.com> (reviewer:vhost)
    qemu-devel@nongnu.org (open list:All patches CC here)
    Orphan
    Supported

2. Legible MAINTAINERS

   S: Supported is without supporters is mildly confusing unless you
   understand that the supporters are listed elsewhere.  Evidence: it
   confused me.

   No S: looks like we forgot to add it.  Feels less bad to me, but I
   might be biased.  Could it use a comment?  Not sure.

   Hmm, S: Supported could even be misleading.  Say Milan had agreed to
   look after this in his spare time.  That's status Maintained.  We'd
   use M: to record his commitment.  But what S: to use?

   S: Maintained gives M: the correct meaning, but mislead readers about
   the status of the matched files: these are still Supported.

   S: Supported is locally correct about the status of the matched
   files, but misleads about the M:.

   I think in this case we'd use M: Maintained as the lesser evil.

   The reliable way to find out status is running get_maintainers.pl.

> We can also tweak the name:
> vhost-user-scmi (part of vhost)

I guess the "vhost-" in "vhost-user-scmi" is enough of a hint.

>> 99. My script is happy.
>> 
>> [...]



      reply	other threads:[~2026-07-15  6:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-10 11:43 [PATCH 0/2] MAINTAINERS: Mark sections orphaned Markus Armbruster
2026-07-10 11:43 ` [PATCH 1/2] MAINTAINERS: Mark "Microchip PolarFire SoC Icicle Kit" orphaned Markus Armbruster
2026-07-11 11:04   ` Bin Meng
2026-07-12 21:51     ` Conor Dooley
2026-07-12 23:21       ` Bin Meng
2026-07-13  6:06     ` Markus Armbruster
2026-07-12 21:47   ` Conor Dooley
2026-07-12 23:46     ` Alistair
2026-07-14  5:15       ` Markus Armbruster
2026-07-10 11:43 ` [PATCH 2/2] MAINTAINERS: Mark "vhost-user-scmi" orphaned Markus Armbruster
2026-07-11  8:00   ` Michael S. Tsirkin
2026-07-13  6:07     ` Markus Armbruster
2026-07-13  6:13     ` Philippe Mathieu-Daudé
2026-07-13  6:52       ` Michael S. Tsirkin
2026-07-13  7:11         ` Philippe Mathieu-Daudé
2026-07-13  7:16           ` Michael S. Tsirkin
2026-07-13  8:17           ` Markus Armbruster
2026-07-14 19:23             ` Michael S. Tsirkin
2026-07-15  6:16               ` Markus Armbruster [this message]

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=87ik6gixr2.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=alistair23@gmail.com \
    --cc=bin.meng@processmission.com \
    --cc=mst@redhat.com \
    --cc=mzamazal@redhat.com \
    --cc=philmd@oss.qualcomm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=sgarzare@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