[PATCH 0/2] MAINTAINERS: enforce file entries are consistent from meson

[PATCH 0/2] MAINTAINERS: enforce file entries are consistent from meson

[Pierrick Bouvier]

Recently, Markus and Philippe made a great effort [1] to cleanup file entries in
MAINTAINERS that do not match any real file.
Now it's clean, we can ensure it will stay consistent in the future, by checking
those entries are consistent, directly at start of meson.build.
Forcing this through the build system makes sure it can't be skipped, whether on
local machine, or in CI. And since anyone needs to trigger it to add tests, doc
or code, it will be detected as soon as possible.

[1] https://lore.kernel.org/qemu-devel/20260521080511.999266-1-armbru@redhat.com/

In terms of performance, it takes 0.26s on a slow machine, where full configure
takes 35s, thus a slow down < 1%: worth it for the consistency we get IMHO.

The first patch cleans up the latest inconsistent entry left, which we solve
pragmatically. Commit mentions another alternative suggested.

The second patch is the check in itself. There was a conversation about
comparing files vs list of files returned by git ls-files. I would prefer to
stick comparing files instead of playing with regex, but I'm open to implement
it another way if that's really important.

The usage is quite simple if you want to play with it manually:
./scripts/check-maintainers-file.py MAINTAINERS

Pierrick Bouvier (2):
  MAINTAINERS: fix entry for 'Python scripts'
  meson.build: check MAINTAINERS file is consistent with source tree

 MAINTAINERS                       |  4 ++-
 meson.build                       |  5 +++
 scripts/check-maintainers-file.py | 53 +++++++++++++++++++++++++++++++
 3 files changed, 61 insertions(+), 1 deletion(-)
 create mode 100755 scripts/check-maintainers-file.py

-- 
2.43.0

[PATCH 1/2] MAINTAINERS: fix entry for 'Python scripts'

[Pierrick Bouvier]

Existing entry tests/*.py does not match any file at the moment, the
semantic is "any py file under tests".
Kernel MAINTAINERS file supports 'K: regexp' entries to match entries,
but we don't support it, and I'm not sure it's the right solution here.

Instead of adding "yet another generic solution" to this problem, just
add manual entries matching existing sublevels. The Python scripts
section is the only one requiring this, and we can always reconsider the
K: approach later if another use case emerge.

Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
---
 MAINTAINERS | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2b5b581e173..61af956ed82 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3472,7 +3472,9 @@ M: John Snow <jsnow@redhat.com>
 M: Cleber Rosa <crosa@redhat.com>
 S: Odd Fixes
 F: scripts/*.py
-F: tests/*.py
+F: tests/*/*.py
+F: tests/*/*/*.py
+F: tests/*/*/*/*.py
 
 Benchmark util
 M: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
-- 
2.43.0

Re: [PATCH 1/2] MAINTAINERS: fix entry for 'Python scripts'

[Markus Armbruster]

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

> Existing entry tests/*.py does not match any file at the moment, the
> semantic is "any py file under tests".
> Kernel MAINTAINERS file supports 'K: regexp' entries to match entries,
> but we don't support it, and I'm not sure it's the right solution here.

I think you mean N:.  K: matches file contents.  From the kernel's
MAINTAINERS file:

	N: Files and directories *Regex* patterns.
	   N:	[^a-z]tegra	all files whose path contains tegra
	                        (not including files like integrator)
	   One pattern per line.  Multiple N: lines acceptable.
	   scripts/get_maintainer.pl has different behavior for files that
	   match F: pattern and matches of N: patterns.  By default,
	   get_maintainer will not look at git log history when an F: pattern
	   match occurs.  When an N: match occurs, git log history is used
	   to also notify the people that have git commit signatures.
	K: *Content regex* (perl extended) pattern match in a patch or file.
	   For instance:
	   K: of_get_profile
	      matches patches or files that contain "of_get_profile"
	   K: \b(printk|pr_(info|err))\b
	      matches patches or files that contain one or more of the words
	      printk, pr_info or pr_err
	   One regex pattern per line.  Multiple K: lines acceptable.

> Instead of adding "yet another generic solution" to this problem, just
> add manual entries matching existing sublevels. The Python scripts
> section is the only one requiring this, and we can always reconsider the
> K: approach later if another use case emerge.

"Only one" is not correct, because ...
>
> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
> ---
>  MAINTAINERS | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2b5b581e173..61af956ed82 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3472,7 +3472,9 @@ M: John Snow <jsnow@redhat.com>
>  M: Cleber Rosa <crosa@redhat.com>
>  S: Odd Fixes
>  F: scripts/*.py
> -F: tests/*.py
> +F: tests/*/*.py
> +F: tests/*/*/*.py
> +F: tests/*/*/*/*.py

... F: scripts/*.py matches only about a third of the .py under scripts.

I'm not demanding you port over N:, I'm just giving you information :)

The "one F: per directory level" solution is pleasantly stupid, but also
somewhat brittle.

>  
>  Benchmark util
>  M: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>

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

[Pierrick Bouvier]

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.
For the rest, like docs, tcg tests, or remaining files, GitLab CI will
build things from scratch and always run the configure step.

With this, it should be impossible by design to have an upstream
MAINTAINERS file with non existing file entries.

Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
---
 meson.build                       |  5 +++
 scripts/check-maintainers-file.py | 53 +++++++++++++++++++++++++++++++
 2 files changed, 58 insertions(+)
 create mode 100755 scripts/check-maintainers-file.py

diff --git a/meson.build b/meson.build
index 19e123423b5..57e9c9de42b 100644
--- a/meson.build
+++ b/meson.build
@@ -17,6 +17,11 @@ add_test_setup('thorough',
 
 meson.add_postconf_script(find_program('scripts/symlink-install-tree.py'))
 
+# check our MAINTAINERS file is consistent
+check_maintainers = find_program('scripts/check-maintainers-file.py')
+maintainers_file = files('MAINTAINERS')
+run_command([check_maintainers, maintainers_file], check: true)
+
 ####################
 # Global variables #
 ####################
diff --git a/scripts/check-maintainers-file.py b/scripts/check-maintainers-file.py
new file mode 100755
index 00000000000..b001816a401
--- /dev/null
+++ b/scripts/check-maintainers-file.py
@@ -0,0 +1,53 @@
+#! /usr/bin/env python3
+
+# Check incorrect file entries in MAINTAINERS
+#
+# Author: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
+#
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+import argparse
+import glob
+import sys
+
+
+def check_one_entry(line) -> bool:
+    return True
+
+
+def main() -> None:
+    parser = argparse.ArgumentParser(description="Check MAINTAINERS file")
+    parser.add_argument("maintainers", help="Path to MAINTAINERS file")
+    args = parser.parse_args()
+
+    found_file_entry = False
+    found_incorrect_entries = False
+    line_counter = 0
+
+    with open(args.maintainers) as file:
+        for entry in file:
+            line_counter += 1
+
+            if not entry.startswith("F:"):
+                continue
+            entry = entry[2:].strip()
+            found_file_entry = True
+
+            file_exists = len(glob.glob(entry, recursive=True)) > 0
+            if file_exists:
+                continue
+
+            found_incorrect_entries = True
+            print(
+                f"No matching files for {args.maintainers} +{line_counter}: {entry}",
+                file=sys.stderr,
+            )
+
+    if not found_file_entry:
+        raise Exception("no file entry found - is MAINTAINERS path correct?")
+    if found_incorrect_entries:
+        raise Exception(f"incorrect entries found in {args.maintainers}")
+
+
+if __name__ == "__main__":
+    main()
-- 
2.43.0

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

[Pierrick Bouvier]

On 6/15/2026 1:17 PM, 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.
> For the rest, like docs, tcg tests, or remaining files, GitLab CI will
> build things from scratch and always run the configure step.
> 
> With this, it should be impossible by design to have an upstream
> MAINTAINERS file with non existing file entries.
> 
> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
> ---
>  meson.build                       |  5 +++
>  scripts/check-maintainers-file.py | 53 +++++++++++++++++++++++++++++++
>  2 files changed, 58 insertions(+)
>  create mode 100755 scripts/check-maintainers-file.py
> 
> diff --git a/meson.build b/meson.build
> index 19e123423b5..57e9c9de42b 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -17,6 +17,11 @@ add_test_setup('thorough',
>  
>  meson.add_postconf_script(find_program('scripts/symlink-install-tree.py'))
>  
> +# check our MAINTAINERS file is consistent
> +check_maintainers = find_program('scripts/check-maintainers-file.py')
> +maintainers_file = files('MAINTAINERS')
> +run_command([check_maintainers, maintainers_file], check: true)
> +
>  ####################
>  # Global variables #
>  ####################
> diff --git a/scripts/check-maintainers-file.py b/scripts/check-maintainers-file.py
> new file mode 100755
> index 00000000000..b001816a401
> --- /dev/null
> +++ b/scripts/check-maintainers-file.py
> @@ -0,0 +1,53 @@
> +#! /usr/bin/env python3
> +
> +# Check incorrect file entries in MAINTAINERS
> +#
> +# Author: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
> +#
> +# SPDX-License-Identifier: GPL-2.0-or-later
> +
> +import argparse
> +import glob
> +import sys
> +
> +
> +def check_one_entry(line) -> bool:
> +    return True
> +

This function is dead code, I'll remove it.

> +
> +def main() -> None:
> +    parser = argparse.ArgumentParser(description="Check MAINTAINERS file")
> +    parser.add_argument("maintainers", help="Path to MAINTAINERS file")
> +    args = parser.parse_args()
> +
> +    found_file_entry = False
> +    found_incorrect_entries = False
> +    line_counter = 0
> +
> +    with open(args.maintainers) as file:
> +        for entry in file:
> +            line_counter += 1
> +
> +            if not entry.startswith("F:"):
> +                continue
> +            entry = entry[2:].strip()
> +            found_file_entry = True
> +
> +            file_exists = len(glob.glob(entry, recursive=True)) > 0
> +            if file_exists:
> +                continue
> +
> +            found_incorrect_entries = True
> +            print(
> +                f"No matching files for {args.maintainers} +{line_counter}: {entry}",
> +                file=sys.stderr,
> +            )
> +
> +    if not found_file_entry:
> +        raise Exception("no file entry found - is MAINTAINERS path correct?")
> +    if found_incorrect_entries:
> +        raise Exception(f"incorrect entries found in {args.maintainers}")
> +
> +
> +if __name__ == "__main__":
> +    main()

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

[Philippe Mathieu-Daudé]

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?

> For the rest, like docs, tcg tests, or remaining files, GitLab CI will
> build things from scratch and always run the configure step.
> 
> With this, it should be impossible by design to have an upstream
> MAINTAINERS file with non existing file entries.
> 
> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
> ---
>   meson.build                       |  5 +++
>   scripts/check-maintainers-file.py | 53 +++++++++++++++++++++++++++++++
>   2 files changed, 58 insertions(+)
>   create mode 100755 scripts/check-maintainers-file.py
> 
> diff --git a/meson.build b/meson.build
> index 19e123423b5..57e9c9de42b 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -17,6 +17,11 @@ add_test_setup('thorough',
>   
>   meson.add_postconf_script(find_program('scripts/symlink-install-tree.py'))
>   
> +# check our MAINTAINERS file is consistent
> +check_maintainers = find_program('scripts/check-maintainers-file.py')
> +maintainers_file = files('MAINTAINERS')
> +run_command([check_maintainers, maintainers_file], check: true)
> +
>   ####################
>   # Global variables #
>   ####################
> diff --git a/scripts/check-maintainers-file.py b/scripts/check-maintainers-file.py
> new file mode 100755
> index 00000000000..b001816a401
> --- /dev/null
> +++ b/scripts/check-maintainers-file.py
> @@ -0,0 +1,53 @@
> +#! /usr/bin/env python3
> +
> +# Check incorrect file entries in MAINTAINERS
> +#
> +# Author: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
> +#
> +# SPDX-License-Identifier: GPL-2.0-or-later
> +
> +import argparse
> +import glob
> +import sys
> +
> +
> +def check_one_entry(line) -> bool:
> +    return True
> +
> +
> +def main() -> None:
> +    parser = argparse.ArgumentParser(description="Check MAINTAINERS file")
> +    parser.add_argument("maintainers", help="Path to MAINTAINERS file")
> +    args = parser.parse_args()
> +
> +    found_file_entry = False
> +    found_incorrect_entries = False
> +    line_counter = 0
> +
> +    with open(args.maintainers) as file:
> +        for entry in file:
> +            line_counter += 1
> +
> +            if not entry.startswith("F:"):
> +                continue
> +            entry = entry[2:].strip()
> +            found_file_entry = True
> +
> +            file_exists = len(glob.glob(entry, recursive=True)) > 0
> +            if file_exists:
> +                continue
> +
> +            found_incorrect_entries = True
> +            print(
> +                f"No matching files for {args.maintainers} +{line_counter}: {entry}",
> +                file=sys.stderr,
> +            )
> +
> +    if not found_file_entry:
> +        raise Exception("no file entry found - is MAINTAINERS path correct?")
> +    if found_incorrect_entries:
> +        raise Exception(f"incorrect entries found in {args.maintainers}")
> +
> +
> +if __name__ == "__main__":
> +    main()

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

[Pierrick Bouvier]

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?

>> For the rest, like docs, tcg tests, or remaining files, GitLab CI will
>> build things from scratch and always run the configure step.
>>
>> With this, it should be impossible by design to have an upstream
>> MAINTAINERS file with non existing file entries.
>>
>> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
>> ---
>>   meson.build                       |  5 +++
>>   scripts/check-maintainers-file.py | 53 +++++++++++++++++++++++++++++++
>>   2 files changed, 58 insertions(+)
>>   create mode 100755 scripts/check-maintainers-file.py
>>
>> diff --git a/meson.build b/meson.build
>> index 19e123423b5..57e9c9de42b 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -17,6 +17,11 @@ add_test_setup('thorough',
>>     meson.add_postconf_script(find_program('scripts/symlink-install-
>> tree.py'))
>>   +# check our MAINTAINERS file is consistent
>> +check_maintainers = find_program('scripts/check-maintainers-file.py')
>> +maintainers_file = files('MAINTAINERS')
>> +run_command([check_maintainers, maintainers_file], check: true)
>> +
>>   ####################
>>   # Global variables #
>>   ####################
>> diff --git a/scripts/check-maintainers-file.py b/scripts/check-
>> maintainers-file.py
>> new file mode 100755
>> index 00000000000..b001816a401
>> --- /dev/null
>> +++ b/scripts/check-maintainers-file.py
>> @@ -0,0 +1,53 @@
>> +#! /usr/bin/env python3
>> +
>> +# Check incorrect file entries in MAINTAINERS
>> +#
>> +# Author: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
>> +#
>> +# SPDX-License-Identifier: GPL-2.0-or-later
>> +
>> +import argparse
>> +import glob
>> +import sys
>> +
>> +
>> +def check_one_entry(line) -> bool:
>> +    return True
>> +
>> +
>> +def main() -> None:
>> +    parser = argparse.ArgumentParser(description="Check MAINTAINERS
>> file")
>> +    parser.add_argument("maintainers", help="Path to MAINTAINERS file")
>> +    args = parser.parse_args()
>> +
>> +    found_file_entry = False
>> +    found_incorrect_entries = False
>> +    line_counter = 0
>> +
>> +    with open(args.maintainers) as file:
>> +        for entry in file:
>> +            line_counter += 1
>> +
>> +            if not entry.startswith("F:"):
>> +                continue
>> +            entry = entry[2:].strip()
>> +            found_file_entry = True
>> +
>> +            file_exists = len(glob.glob(entry, recursive=True)) > 0
>> +            if file_exists:
>> +                continue
>> +
>> +            found_incorrect_entries = True
>> +            print(
>> +                f"No matching files for {args.maintainers}
>> +{line_counter}: {entry}",
>> +                file=sys.stderr,
>> +            )
>> +
>> +    if not found_file_entry:
>> +        raise Exception("no file entry found - is MAINTAINERS path
>> correct?")
>> +    if found_incorrect_entries:
>> +        raise Exception(f"incorrect entries found in
>> {args.maintainers}")
>> +
>> +
>> +if __name__ == "__main__":
>> +    main()
> 

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

[Philippe Mathieu-Daudé]

On 16/6/26 04:51, Pierrick Bouvier wrote:
> 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.

OK. So far removing "adding or" and check_one_entry():

Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>

> 
> What do you think Markus?
> 
>>> For the rest, like docs, tcg tests, or remaining files, GitLab CI will
>>> build things from scratch and always run the configure step.
>>>
>>> With this, it should be impossible by design to have an upstream
>>> MAINTAINERS file with non existing file entries.
>>>
>>> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
>>> ---
>>>    meson.build                       |  5 +++
>>>    scripts/check-maintainers-file.py | 53 +++++++++++++++++++++++++++++++
>>>    2 files changed, 58 insertions(+)
>>>    create mode 100755 scripts/check-maintainers-file.py
>>>
>>> diff --git a/meson.build b/meson.build
>>> index 19e123423b5..57e9c9de42b 100644
>>> --- a/meson.build
>>> +++ b/meson.build
>>> @@ -17,6 +17,11 @@ add_test_setup('thorough',
>>>      meson.add_postconf_script(find_program('scripts/symlink-install-
>>> tree.py'))
>>>    +# check our MAINTAINERS file is consistent
>>> +check_maintainers = find_program('scripts/check-maintainers-file.py')
>>> +maintainers_file = files('MAINTAINERS')
>>> +run_command([check_maintainers, maintainers_file], check: true)
>>> +
>>>    ####################
>>>    # Global variables #
>>>    ####################
>>> diff --git a/scripts/check-maintainers-file.py b/scripts/check-
>>> maintainers-file.py
>>> new file mode 100755
>>> index 00000000000..b001816a401
>>> --- /dev/null
>>> +++ b/scripts/check-maintainers-file.py
>>> @@ -0,0 +1,53 @@
>>> +#! /usr/bin/env python3
>>> +
>>> +# Check incorrect file entries in MAINTAINERS
>>> +#
>>> +# Author: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
>>> +#
>>> +# SPDX-License-Identifier: GPL-2.0-or-later
>>> +
>>> +import argparse
>>> +import glob
>>> +import sys
>>> +
>>> +
>>> +def check_one_entry(line) -> bool:
>>> +    return True
>>> +
>>> +
>>> +def main() -> None:
>>> +    parser = argparse.ArgumentParser(description="Check MAINTAINERS
>>> file")
>>> +    parser.add_argument("maintainers", help="Path to MAINTAINERS file")
>>> +    args = parser.parse_args()
>>> +
>>> +    found_file_entry = False
>>> +    found_incorrect_entries = False
>>> +    line_counter = 0
>>> +
>>> +    with open(args.maintainers) as file:
>>> +        for entry in file:
>>> +            line_counter += 1
>>> +
>>> +            if not entry.startswith("F:"):
>>> +                continue
>>> +            entry = entry[2:].strip()
>>> +            found_file_entry = True
>>> +
>>> +            file_exists = len(glob.glob(entry, recursive=True)) > 0
>>> +            if file_exists:
>>> +                continue
>>> +
>>> +            found_incorrect_entries = True
>>> +            print(
>>> +                f"No matching files for {args.maintainers}
>>> +{line_counter}: {entry}",
>>> +                file=sys.stderr,
>>> +            )
>>> +
>>> +    if not found_file_entry:
>>> +        raise Exception("no file entry found - is MAINTAINERS path
>>> correct?")
>>> +    if found_incorrect_entries:
>>> +        raise Exception(f"incorrect entries found in
>>> {args.maintainers}")
>>> +
>>> +
>>> +if __name__ == "__main__":
>>> +    main()
>>
> 

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

[Markus Armbruster]

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.

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

[Daniel P. Berrangé]

On Mon, Jun 15, 2026 at 01:17:23PM -0700, 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.
> For the rest, like docs, tcg tests, or remaining files, GitLab CI will
> build things from scratch and always run the configure step.
> 
> With this, it should be impossible by design to have an upstream
> MAINTAINERS file with non existing file entries.

Accuracy of the MAINTAINERS file is an upstream-only concern, but
IIUC, this check is going to apply universally to every build of
QEMU which is undesirable. It is irrelevant to end users and not
appropriate to check in downsteam vendors forks.

In a "normal" modern project this kind of check would be done in
a CI job on the merge request, since that's the only place it is
relevant. In our case, the nearest fit is the checkpatch.pl file.

> 
> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
> ---
>  meson.build                       |  5 +++
>  scripts/check-maintainers-file.py | 53 +++++++++++++++++++++++++++++++
>  2 files changed, 58 insertions(+)
>  create mode 100755 scripts/check-maintainers-file.py
> 
> diff --git a/meson.build b/meson.build
> index 19e123423b5..57e9c9de42b 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -17,6 +17,11 @@ add_test_setup('thorough',
>  
>  meson.add_postconf_script(find_program('scripts/symlink-install-tree.py'))
>  
> +# check our MAINTAINERS file is consistent
> +check_maintainers = find_program('scripts/check-maintainers-file.py')
> +maintainers_file = files('MAINTAINERS')
> +run_command([check_maintainers, maintainers_file], check: true)
> +
>  ####################
>  # Global variables #
>  ####################
> diff --git a/scripts/check-maintainers-file.py b/scripts/check-maintainers-file.py
> new file mode 100755
> index 00000000000..b001816a401
> --- /dev/null
> +++ b/scripts/check-maintainers-file.py
> @@ -0,0 +1,53 @@
> +#! /usr/bin/env python3
> +
> +# Check incorrect file entries in MAINTAINERS
> +#
> +# Author: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
> +#
> +# SPDX-License-Identifier: GPL-2.0-or-later
> +
> +import argparse
> +import glob
> +import sys
> +
> +
> +def check_one_entry(line) -> bool:
> +    return True
> +
> +
> +def main() -> None:
> +    parser = argparse.ArgumentParser(description="Check MAINTAINERS file")
> +    parser.add_argument("maintainers", help="Path to MAINTAINERS file")
> +    args = parser.parse_args()
> +
> +    found_file_entry = False
> +    found_incorrect_entries = False
> +    line_counter = 0
> +
> +    with open(args.maintainers) as file:
> +        for entry in file:
> +            line_counter += 1
> +
> +            if not entry.startswith("F:"):
> +                continue
> +            entry = entry[2:].strip()
> +            found_file_entry = True
> +
> +            file_exists = len(glob.glob(entry, recursive=True)) > 0
> +            if file_exists:
> +                continue
> +
> +            found_incorrect_entries = True
> +            print(
> +                f"No matching files for {args.maintainers} +{line_counter}: {entry}",
> +                file=sys.stderr,
> +            )
> +
> +    if not found_file_entry:
> +        raise Exception("no file entry found - is MAINTAINERS path correct?")
> +    if found_incorrect_entries:
> +        raise Exception(f"incorrect entries found in {args.maintainers}")
> +
> +
> +if __name__ == "__main__":
> +    main()
> -- 
> 2.43.0
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

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

[Peter Maydell]

On Tue, 16 Jun 2026 at 08:54, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Mon, Jun 15, 2026 at 01:17:23PM -0700, 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.
> > For the rest, like docs, tcg tests, or remaining files, GitLab CI will
> > build things from scratch and always run the configure step.
> >
> > With this, it should be impossible by design to have an upstream
> > MAINTAINERS file with non existing file entries.
>
> Accuracy of the MAINTAINERS file is an upstream-only concern, but
> IIUC, this check is going to apply universally to every build of
> QEMU which is undesirable. It is irrelevant to end users and not
> appropriate to check in downsteam vendors forks.
>
> In a "normal" modern project this kind of check would be done in
> a CI job on the merge request, since that's the only place it is
> relevant. In our case, the nearest fit is the checkpatch.pl file.

You could put it in "make check", or (if you want to avoid the
downstream-forks issue) in some sub-bit of "make check"
that we don't check by default but do check in one of our CI jobs.

checkpatch isn't a great place for checks that you want to
stay consistent on because so much of its output is "this
is wrong/merely something to check, ignore".

-- PMM

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

[Pierrick Bouvier]

On 6/16/2026 1:30 AM, Peter Maydell wrote:
> On Tue, 16 Jun 2026 at 08:54, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>
>> On Mon, Jun 15, 2026 at 01:17:23PM -0700, 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.
>>> For the rest, like docs, tcg tests, or remaining files, GitLab CI will
>>> build things from scratch and always run the configure step.
>>>
>>> With this, it should be impossible by design to have an upstream
>>> MAINTAINERS file with non existing file entries.
>>
>> Accuracy of the MAINTAINERS file is an upstream-only concern, but
>> IIUC, this check is going to apply universally to every build of
>> QEMU which is undesirable. It is irrelevant to end users and not
>> appropriate to check in downsteam vendors forks.
>>

I accept the argument about downstream forks even though they are free
to remove the check since they are... forks.
However, it's relevant to users I think. It's very easy to move a file,
and forget to update associated MAINTAINERS entry, and the sooner we
catch that, the better. Similar, when a new file is added and not
covered by an entry in MAINTAINERS, it's very easy to miss that.

>> In a "normal" modern project this kind of check would be done in
>> a CI job on the merge request, since that's the only place it is
>> relevant. In our case, the nearest fit is the checkpatch.pl file.

It depends how fast you want to catch the problem.
Adding yet another round trip latency to a project that already has a
multi day latency for upstream is not a good thing IMHO.
Also, it brings yet another burden on top maintainers that will have to
deal with this new failure, fix it themselves, or recreate their staging
set for the next batch and wait for yet another day. More time spent,
more noise, more iteration, just for a missing line update in
MAINTAINERS file.

All that is nonexistent if no one can build it if it's incorrect. That's
why we use -Werror by default for instance. And if someone sends a patch
breaking this, you can be sure they didn't even try to build their own
code/doc/test.

Does that open your view on this approach?

> 
> You could put it in "make check", or (if you want to avoid the
> downstream-forks issue) in some sub-bit of "make check"
> that we don't check by default but do check in one of our CI jobs.
>

If argument above is still rejected, we can just add a CI job (calling
script directly). I'm not sure any kind of integration is needed. Also,
not sure where to fit that in any existing test suite to be honest.

> checkpatch isn't a great place for checks that you want to
> stay consistent on because so much of its output is "this
> is wrong/merely something to check, ignore".
>

I agree, checkpatch is not useful to enforce things. It would be
different if it was strictly enforced in CI, but that's not the case,
and won't be given the false positives it brings.

> -- PMM

Thanks for both of you for the feedback,
Pierrick

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

[Markus Armbruster]

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

> On 6/16/2026 1:30 AM, Peter Maydell wrote:
>> On Tue, 16 Jun 2026 at 08:54, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>>
>>> On Mon, Jun 15, 2026 at 01:17:23PM -0700, 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.
>>>> For the rest, like docs, tcg tests, or remaining files, GitLab CI will
>>>> build things from scratch and always run the configure step.
>>>>
>>>> With this, it should be impossible by design to have an upstream
>>>> MAINTAINERS file with non existing file entries.
>>>
>>> Accuracy of the MAINTAINERS file is an upstream-only concern, but
>>> IIUC, this check is going to apply universally to every build of
>>> QEMU which is undesirable. It is irrelevant to end users and not
>>> appropriate to check in downsteam vendors forks.
>>>
>
> I accept the argument about downstream forks even though they are free
> to remove the check since they are... forks.
> However, it's relevant to users I think. It's very easy to move a file,
> and forget to update associated MAINTAINERS entry, and the sooner we
> catch that, the better. Similar, when a new file is added and not
> covered by an entry in MAINTAINERS, it's very easy to miss that.
>
>>> In a "normal" modern project this kind of check would be done in
>>> a CI job on the merge request, since that's the only place it is
>>> relevant. In our case, the nearest fit is the checkpatch.pl file.
>
> It depends how fast you want to catch the problem.
> Adding yet another round trip latency to a project that already has a
> multi day latency for upstream is not a good thing IMHO.

Yes, and ...

> Also, it brings yet another burden on top maintainers that will have to
> deal with this new failure, fix it themselves, or recreate their staging
> set for the next batch and wait for yet another day. More time spent,
> more noise, more iteration, just for a missing line update in
> MAINTAINERS file.

... yes.

We might have conditioned ourselves to consider such loops normal.
They're not.

> All that is nonexistent if no one can build it if it's incorrect. That's
> why we use -Werror by default for instance. And if someone sends a patch
> breaking this, you can be sure they didn't even try to build their own
> code/doc/test.

I don't want make to fail during development just because I haven't
updated MAINTAINERS, yet.  It's a distraction that could snap me out of
the flow.  I'm developing with -Werror disabled for the same reason.

I do want make to fail before I send patches.  I do another compile with
-Werror enabled then, but that's just my personal workflow.

Solutions I like well enough:

* Make it a compile-time warning that obeys --enable-werror.  Could well
  be more trouble than it's worth.

* Make it fail "make check".

Dislike:

* Make it a checkpatch.pl error.  Stays out of my hair during
  development, but then I have to remember to actually run
  checkpatch.pl, or risk having CI bouncing things back to me, wasting
  everybody's time.  Meh

* Make it fail CI in some other way.  Worse, because now I have to
  remember running checkpatch.pl *and* that other way.

* Make it fail "make".  Stay out of my hair!

> Does that open your view on this approach?
>
>> 
>> You could put it in "make check", or (if you want to avoid the
>> downstream-forks issue) in some sub-bit of "make check"
>> that we don't check by default but do check in one of our CI jobs.
>>
>
> If argument above is still rejected, we can just add a CI job (calling
> script directly). I'm not sure any kind of integration is needed. Also,
> not sure where to fit that in any existing test suite to be honest.
>
>> checkpatch isn't a great place for checks that you want to
>> stay consistent on because so much of its output is "this
>> is wrong/merely something to check, ignore".
>>
>
> I agree, checkpatch is not useful to enforce things. It would be
> different if it was strictly enforced in CI, but that's not the case,
> and won't be given the false positives it brings.

CI should only reject things that are actually wrong, or at least
undesirable.

checkpatch.pl warns when you add, move, or delete files without updating
MAINTAINERS.  It's only a warning, because MAINTAINERS may in fact not
need an update.  Not good enough for CI rejects.

The purpose of warnings is to help maintainers and developers find
*potential* issues.

>
>> -- PMM
>
> Thanks for both of you for the feedback,
> Pierrick