Re: [PATCH 2/2] meson.build: check MAINTAINERS file is consistent with source tree

[Markus Armbruster <armbru@redhat.com>]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> On 6/15/2026 5:35 PM, Philippe Mathieu-Daudé wrote:
>> On 15/6/26 22:17, Pierrick Bouvier wrote:
>>> We add a new script: scripts/check-maintainers-file.py, that will run at
>>> configuration time (and not at build time), to not hurt build time.
>>> This script runs in 0.2s on my dev VM, which has an old cpu.
>>>
>>> We can expect things to be mostly in sync since adding or removing a
>>> source or test file will trigger a configure step.
>> 
>> You mention adding/removing but this script only checks for removals,
>> no additions; did I miss something?
>>
> The initial scope was only to check the MAINTAINERS file itself is
> correct. But while we're at it, we could extend the script to check that
> all files in the tree belong to at least one maintainer entry. This
> could have the benefit to force coverage for all new files. First we can
> try to see what is not covered at the moment.
>
> What do you think Markus?

I periodically post a report on MAINTAINERS coverage.  The most recent
one is for v10.2.0-rc4:

    Subject: Report on MAINTAINERS coverage
    To: qemu-devel@nongnu.org
    Date: Thu, 18 Dec 2025 13:45:24 +0100
    Message-ID: <87h5toc61n.fsf@pond.sub.org>
    https://lore.kernel.org/qemu-devel/87h5toc61n.fsf@pond.sub.org/

We had more than a thousand files not covered then.  Getting to 100%
coverage would take a big push, and require help from many people.

Even with imperfect coverage, we could still require coverage for all
new files.  I'm not sure this is practical without at least some
targeted MAINTAINERS improvements.  Test-drive with a month or three
worth of existing commits to see how bad it would have been, to give us
an idea on how bad it would be?  Or just take the plunge, and revert if
it turns out to be bad?

This series tries to solve a smaller problem.  Even if we decide we want
the bigger problem solved, getting the smaller problem solved sooner is
probably better than getting it solved together with the bigger one
later.