On Tue, Jan 4, 2022 at 4:30 AM Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote: > > > Run './scripts/get_maintainer.pl --self-test' in a kernel git tree > and fix some of the problems there. > I have been running ./scripts/get_maintainer.pl --self-test=patterns regularly on linux-next for about a year now. Running ./scripts/get_maintainer.pl --self-test=patterns only takes about a minute, as it does not try to check the response of all the URLs in MAINTAINERS, which takes quite some time due to sequentially requesting URLs and waiting for a timeout in case it does not get an immediate response. You find many of the commits on this janitor task with: git log --grep="./scripts/get_maintainer.pl --self-test" Here are my insights of the regular runs: In general, these cleanup commits are appreciated, they are usually acked by the authors and not discussed a lot. Sometimes, issues appear in MAINTAINERS because changes from one patch series are split and travel through different maintainer trees with different speed. Recently, many issues in MAINTAINERS for --self-test=patterns result from devicetree bindings text to yaml conversions; they are converted, the file name changes, but MAINTAINERS is not adjusted. IMHO, submissions of the MAINTAINERS clean-up patches would need to be picked up by Rob Herring, but these patches were pending last year a lot (not being picked up), so that I finally submitted them for inclusion through the -mm tree from Andrew Morton. The script ./scripts/documentation-file-ref-check also reports some issues in MAINTAINERS (partly overlapping with ./scripts/get_maintainer.pl --self-test). It also provides a simplistic --fix option. Mauro Carvalho Chehab runs this script regularly and submits clean-up patches as well. Usually any of those cleanup patches does the job. Currently, when a patch renames, moves or deletes files, checkpatch.pl generally reports a FILE_PATH_CHANGES warning: "Whenever files are added, moved, or deleted, the MAINTAINERS file patterns can be out of sync or outdated. So MAINTAINERS might need updating in these cases." (https://www.kernel.org/doc/html/latest/dev-tools/checkpatch.html#others). That is generally a good hint, but quite unspecific (and hence, probably sometimes ignored as too unspecific). IMHO, developers would benefit from a dedicated script that reports exactly after a file-path change or change to MAINTAINERS, for which files/paths the assignment to MAINTAINERS sections (and/or the responsibility of developers) has changed. Then, the developer can check if that was intended or not. Even better than creating those cleanup patches is to avoid them before the inclusion of breaking changes in the repository. The challenge is to track and test all patches coming through on the mailing list. A suitable CI system to run ./scripts/get_maintainer.pl --self-test=patterns to identify the breaking patches would help. Sofar, none of the CI systems is currently doing that. Further, reasonable cleanup activities around MAINTAINERS: - Assigning files in Documentation/ABI/ and include/ to the right MAINTAINERS section. I already played around with some heuristics to guess the right section automatically, but I did not find much time to develop that much further than a simple experiment so far. - Checking if the mentioned maintainers in the section are still active, e.g., observing commits in the git repository and email exchange on the mailing lists (lore.kernel.org helps), and if not, proposing to remove them or declaring a section orphan for giving somebody a chance to adopt it. Jonathan Corbet had developed a part of that analysis already in the gitdm tool for an LWN article last year. Ralf Ramsauer et al. have developed some similar scripts for parsing MAINTAINERS with python. If someone is interested in helping out here, I will gladly support getting started on this janitorial task. Lukas
