On 29/9/23 13:43, Markus Armbruster wrote:
Back in 2014 (time flies), I postedSubject: MAINTAINERS leaves too many files uncovered Message-ID: <[email protected]> https://lore.kernel.org/qemu-devel/[email protected]/ 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?
