On 6/16/2026 11:42 PM, Markus Armbruster wrote: > Pierrick Bouvier <[email protected]> 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: [email protected] > Date: Thu, 18 Dec 2025 13:45:24 +0100 > Message-ID: <[email protected]> > https://lore.kernel.org/qemu-devel/[email protected]/ >
Thanks, I didn't know you were publishing those! > 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. > Right, definitely let's focus on what we have here already.
