Re: MAINTAINERS still leaves more files uncovered than I'd like

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

On 29/9/23 13:43, Markus Armbruster wrote:
> 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), and 2018
> (at v3.1.0-rc2).  This is another update, at commit 36e9aab3c56.
> 
> Unsurprisingly, the number of files in the tree
> 
>      $ git-ls-files | wc -l
> 
> grows over time:
> 
>      year  2014  2015  2016  2018  2023
>      #     3746  4387  4921  6461  9788
> 
> Looks exponential to me, doubling every seven years or so.
> 
> The number of .c files has grown more slowly:
> 
>      year  2014  2015  2016  2018  2023
>      #     1836  1945  2132  2633  3588
> 
> The number of .c files not covered by MAINTAINERS
> 
>      $ for i in `git-ls-files`; do [ "`scripts/get_maintainer.pl -f --no-git-fallback $i | grep -v '^qemu-devel@nongnu\.org'`" ] || echo $i; done >unmaintained-files
>      $ grep -c '\.c$' unmaintained-files
> 
> went down a lot after my first post, but has since flatlined:
> 
>      year  2014  2015  2016  2018  2023
>      #     1066   461   402   259   246
> 
> It looks like we've pretty much stopped adding more unmaintained .c
> files, i.e. cherry-picking the kernel's 13f1937ef33 (checkpatch: emit a
> warning on file add/move/delete) as commit 4be6131e329 worked.
> 
> On the other hand, we're not making progress on the remaining old ones
> anymore.

How many new files without maintainers?
Shouldn't we turn this warning into an error, so new files must have
maintainers?