MAINTAINERS | 10 +- .gitlab-ci.d/static_checks.yml | 9 + scripts/get_maintainer.py | 356 +++++++++++++++++++++++++++++++++ 3 files changed, 370 insertions(+), 5 deletions(-) create mode 100755 scripts/get_maintainer.py
*incomplete I wanted to look at adding gitlab tags to MAINTAINERS and baulked slightly at figuring out what I would need to change in the perl script to cleanly handle it. While we imported the perl script from the kernel I'm fairly sure we don't use half the features it has and as us grey beards age out less people will be willing to tweak it. Consider this a proof-of-concept for discussion about if it is worth perusing this path. It only supports the two main forms: ./scripts/get_maintainer.py -f path/to/file ./scripts/get_maintainer.py path/to/patch1 path/to/patch2 ... But who needs more? Future improvements could include some more detailed analysis in conjugation with the repo to analysis: - missing areas of coverage - maintainer stats Who knows maybe the kernel guys will want to import our script one day ;-) Alex. Alex Bennée (9): MAINTAINERS: fix missing names MAINTAINERS: fix libvirt entry MAINTAINERS: regularise the status fields scripts/get_maintainer.py: minimal argument parsing scripts/get_maintainer.py: resolve the source path scripts/get_maintainer.py: initial parsing of MAINTAINERS scripts/get_maintainer.py: add support for -f scripts/get_maintainer.py: add support reading patch files gitlab: add a check-maintainers task MAINTAINERS | 10 +- .gitlab-ci.d/static_checks.yml | 9 + scripts/get_maintainer.py | 356 +++++++++++++++++++++++++++++++++ 3 files changed, 370 insertions(+), 5 deletions(-) create mode 100755 scripts/get_maintainer.py -- 2.47.3
On Thu, 11 Dec 2025 at 18:02, Alex Bennée <alex.bennee@linaro.org> wrote: > > *incomplete > > I wanted to look at adding gitlab tags to MAINTAINERS and baulked > slightly at figuring out what I would need to change in the perl > script to cleanly handle it. > > While we imported the perl script from the kernel I'm fairly sure we > don't use half the features it has and as us grey beards age out less > people will be willing to tweak it. Consider this a proof-of-concept > for discussion about if it is worth perusing this path. I think it would be interesting to know if the upstream kernel folks have any plans with get_maintainers -- they recently did a big conversion of kernel-doc from perl to python, for instance. I've cc'd Mauro who might know if anything has been proposed similarly for get_maintainers. thanks -- PMM
On Thu, Dec 11, 2025 at 06:01:23PM +0000, Alex Bennée wrote: > *incomplete > > I wanted to look at adding gitlab tags to MAINTAINERS and baulked > slightly at figuring out what I would need to change in the perl > script to cleanly handle it. > > While we imported the perl script from the kernel I'm fairly sure we > don't use half the features it has and as us grey beards age out less > people will be willing to tweak it. Consider this a proof-of-concept > for discussion about if it is worth perusing this path. > > It only supports the two main forms: > > ./scripts/get_maintainer.py -f path/to/file > ./scripts/get_maintainer.py path/to/patch1 path/to/patch2 ... > > But who needs more? the $QEMU/.gitpublish file contains cccmd = scripts/get_maintainer.pl --noroles --norolestats --nogit --nogit-fallback 2>/dev/null And the .b4-config file contains the same: send-auto-cc-cmd = scripts/get_maintainer.pl --noroles --norolestats --nogit --nogit-fallback Is trawling the git history to guess at maintainers useful for regular usage, while undesirable for sending patches, or should we just pick a behaviour use it unconditionally? > > Future improvements could include some more detailed analysis in > conjugation with the repo to analysis: > > - missing areas of coverage > - maintainer stats > > Who knows maybe the kernel guys will want to import our script one day > ;-) > > Alex. > > Alex Bennée (9): > MAINTAINERS: fix missing names > MAINTAINERS: fix libvirt entry > MAINTAINERS: regularise the status fields > scripts/get_maintainer.py: minimal argument parsing > scripts/get_maintainer.py: resolve the source path > scripts/get_maintainer.py: initial parsing of MAINTAINERS > scripts/get_maintainer.py: add support for -f > scripts/get_maintainer.py: add support reading patch files > gitlab: add a check-maintainers task > > MAINTAINERS | 10 +- > .gitlab-ci.d/static_checks.yml | 9 + > scripts/get_maintainer.py | 356 +++++++++++++++++++++++++++++++++ > 3 files changed, 370 insertions(+), 5 deletions(-) > create mode 100755 scripts/get_maintainer.py > > -- > 2.47.3 > > With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Daniel P. Berrangé <berrange@redhat.com> writes: > On Thu, Dec 11, 2025 at 06:01:23PM +0000, Alex Bennée wrote: >> *incomplete >> >> I wanted to look at adding gitlab tags to MAINTAINERS and baulked >> slightly at figuring out what I would need to change in the perl >> script to cleanly handle it. >> >> While we imported the perl script from the kernel I'm fairly sure we >> don't use half the features it has and as us grey beards age out less >> people will be willing to tweak it. Consider this a proof-of-concept >> for discussion about if it is worth perusing this path. >> >> It only supports the two main forms: >> >> ./scripts/get_maintainer.py -f path/to/file >> ./scripts/get_maintainer.py path/to/patch1 path/to/patch2 ... >> >> But who needs more? > > the $QEMU/.gitpublish file contains > > cccmd = scripts/get_maintainer.pl --noroles --norolestats --nogit --nogit-fallback 2>/dev/null > > And the .b4-config file contains the same: > > send-auto-cc-cmd = scripts/get_maintainer.pl --noroles --norolestats --nogit --nogit-fallback > > > Is trawling the git history to guess at maintainers useful > for regular usage, while undesirable for sending patches, > or should we just pick a behaviour use it unconditionally? We can certainly add the ability to dig through git but to honest those doing archaeology are probably better off reading the logs. The default it just to match paths to MAINTAINERS which I think is what the main use is. It's not called get_git_blame_info.py ;-) > >> >> Future improvements could include some more detailed analysis in >> conjugation with the repo to analysis: >> >> - missing areas of coverage >> - maintainer stats >> >> Who knows maybe the kernel guys will want to import our script one day >> ;-) >> >> Alex. >> >> Alex Bennée (9): >> MAINTAINERS: fix missing names >> MAINTAINERS: fix libvirt entry >> MAINTAINERS: regularise the status fields >> scripts/get_maintainer.py: minimal argument parsing >> scripts/get_maintainer.py: resolve the source path >> scripts/get_maintainer.py: initial parsing of MAINTAINERS >> scripts/get_maintainer.py: add support for -f >> scripts/get_maintainer.py: add support reading patch files >> gitlab: add a check-maintainers task >> >> MAINTAINERS | 10 +- >> .gitlab-ci.d/static_checks.yml | 9 + >> scripts/get_maintainer.py | 356 +++++++++++++++++++++++++++++++++ >> 3 files changed, 370 insertions(+), 5 deletions(-) >> create mode 100755 scripts/get_maintainer.py >> >> -- >> 2.47.3 >> >> > > With regards, > Daniel -- Alex Bennée Virtualisation Tech Lead @ Linaro
On Fri, 12 Dec 2025 at 11:00, Alex Bennée <alex.bennee@linaro.org> wrote: > We can certainly add the ability to dig through git but to honest those > doing archaeology are probably better off reading the logs. The default > it just to match paths to MAINTAINERS which I think is what the main use > is. It's not called get_git_blame_info.py ;-) The default of the existing script is to start with MAINTAINERS but to fall back to looking at git if there's nothing in the MAINTAINERS file. thanks -- PMM
Alex Bennée <alex.bennee@linaro.org> writes:
> *incomplete
>
> I wanted to look at adding gitlab tags to MAINTAINERS and baulked
> slightly at figuring out what I would need to change in the perl
> script to cleanly handle it.
>
> While we imported the perl script from the kernel I'm fairly sure we
> don't use half the features it has and as us grey beards age out less
> people will be willing to tweak it. Consider this a proof-of-concept
> for discussion about if it is worth perusing this path.
>
> It only supports the two main forms:
>
> ./scripts/get_maintainer.py -f path/to/file
> ./scripts/get_maintainer.py path/to/patch1 path/to/patch2 ...
>
> But who needs more?
I've used options --git --nogit-fallback --git-since and --git-blame.
> Future improvements could include some more detailed analysis in
> conjugation with the repo to analysis:
>
> - missing areas of coverage
I've used
$ 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
Last post:
From: Markus Armbruster <armbru@redhat.com>
Subject: MAINTAINERS still leaves more files uncovered than I'd like
To: qemu-devel@nongnu.org
Date: Fri, 29 Sep 2023 13:43:30 +0200
Message-ID: <87lecp6w7x.fsf@pond.sub.org>
https://lore.kernel.org/qemu-devel/87lecp6w7x.fsf@pond.sub.org/
I think I'll do it again soonish.
> - maintainer stats
>
> Who knows maybe the kernel guys will want to import our script one day
> ;-)
>
> Alex.
© 2016 - 2025 Red Hat, Inc.