From: Markus Armbruster <armbru@redhat.com>
To: Stefan Weil <stefan.weil@weilnetz.de>
Cc: qemu-devel@nongnu.org
Subject: Re: Report on MAINTAINERS coverage
Date: Fri, 19 Dec 2025 08:44:16 +0100 [thread overview]
Message-ID: <87v7i27w6n.fsf@pond.sub.org> (raw)
In-Reply-To: <97a6f77e-7a86-4bbc-a20a-b1e1c7bdb537@weilnetz.de> (Stefan Weil via's message of "Thu, 18 Dec 2025 16:57:13 +0100")
Stefan Weil via <qemu-devel@nongnu.org> writes:
> Am 18.12.25 um 13:45 schrieb Markus Armbruster:
>> Back in 2014 (time flies), I posted
>>
>> Subject: MAINTAINERS leaves too many files uncovered
>> Message-ID: <87mw8rumhb.fsf@blackfin.pond.sub.org>
>> https://lore.kernel.org/qemu-devel/87mw8rumhb.fsf@blackfin.pond.sub.org/
>>
>> I updated my findings in 2015, 2016 (at commit e00da552a0d), 2018 (at
>> v3.1.0-rc2), and 2023 (at commit 36e9aab3c56, close to v8.2.0). This is
>> another update, at v10.2.0-rc4.
>
>
> These two files were contributed by me and most of my initial code is
> still unmodified, so I could be added as their maintainer:
>
> hw/nvram/eeprom93xx.c
> include/hw/nvram/eeprom93xx.h
Thanks!
> I had two contributions to the eeprom93xx.c (one made by Thiemo in my
> name). Other authors had also two or more contributions:
>
> 2 Author: Alex Williamson <alex@shazbot.org>
> 2 Author: Anthony Liguori <anthony@codemonkey.ws>
> 2 Author: Aurelien Jarno <aurelien@aurel32.net>
> 2 Author: Marc-André Lureau <marcandre.lureau@redhat.com>
> 3 Author: Blue Swirl <blauwirbel@gmail.com>
> 3 Author: Juan Quintela <quintela@trasno.org>
> 3 Author: Paolo Bonzini <pbonzini@redhat.com>
> 5 Author: Markus Armbruster <armbru@redhat.com>
>
> I am not sure about the desired order in MAINTAINERS. Therefore I don't
> intend to send a patch but would be happy if someone else updates this file.
I can take care of it.
MAINTAINERS has the nvram device models either under a machine,
supposedly the one machine that uses it (e.g. ds1225y.c is under
"Jazz"), or in section of its own ("CHRP NVRAM" and "Firmware
configuration (fw_cfg)").
As far as I can tell at a glance, eeprom93xx is used by the eepro100
NICs (i82500, i82551, ...), the tulip NIC, and dc390 SCSI HBA. These
are all PCI devices available with -device, so not tied to any
particular machine type. I guess a section of its own makes sense. Do
you agree?
If yes, the section goes under the Devices heading. Section order
appears to be unsystematic. Next to "CHRP NVRAM"?
> For the other files which are von covered by MAINTAINERS, the copyright
> notice might help to find possible maintainers:
>
> grep --no-filename -r -o "Copyright.*" $(cat FILELIST)|sort -i|uniq -ci
Yes, but I don't have the time to tackle the long tail myself.
prev parent reply other threads:[~2025-12-19 7:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-18 12:45 Report on MAINTAINERS coverage Markus Armbruster
2025-12-18 12:55 ` Daniel P. Berrangé
2025-12-18 13:37 ` Markus Armbruster
2025-12-18 13:49 ` Daniel P. Berrangé
2025-12-18 14:06 ` Thomas Huth
2025-12-18 14:12 ` Daniel P. Berrangé
2025-12-18 14:17 ` Thomas Huth
2025-12-18 15:25 ` Markus Armbruster
2025-12-18 16:08 ` Thomas Huth
2025-12-19 8:43 ` Markus Armbruster
2025-12-18 15:57 ` Stefan Weil via
2025-12-19 7:44 ` 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=87v7i27w6n.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefan.weil@weilnetz.de \
/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.