Hello,
I am a little bit cluttered about a few things around get_maintainer.pl and the fact that penguin chiefs may also be maintainers, at least in third party projects also using get_maintainer.pl script. My feeling is that get_maintainer.pl mishandles penguin chiefs without it being an issue for Linux case, therefore a kind of silent bug. But since other projects do use get_maintainer.pl, this "bug" may matter you (upstream).
Penguin chief is an hard-coded list of name:email inside get_maintainer.pl script, which currently only lists Linus. When called with --git-chief-penguins, the script also outputs penguin chiefs alongside found maintainers.
When called with --no-git-chief-penguins (the default), the script actually removes chief penguin from found maintainers. That is, if a penguin chief is also a maintainer of some files within MAINTAINERS file, asking maintainers of those file will not list him/her and may list nobody if he/she was single maintainer for those files.
Hopefully, the issue is either minor or nonexistent/feature with Linux MAINTAINERS file since Linus (hard-coded penguin chief) is only maintainer of "THE REST" final catch-all section. He is the only maintainer of this section, therefore no maintainers at all are returned for files not covered in other sections. Also, thanks to this bug/feature, this catch-all section being somehow broken does not reports Linus as maintainer of every Linux files, which may avoid flooding Linus.
As a first sight I see several options:
1. Upstream (Linux get_maintainer.pl) can be modified to not filter out chiefs within found maintainers.
2. Third-party projects can simply clear their static penguin chief list.
Caution: in both cases (and especially the former), "THE REST" catch-all section will work again, listing Linus in all results, likely flooding him until all git-email --cc-cmd gists are fixed. This can be handled within script since the magic "Buried alive in reporters" section status makes its maintainers getting "chief penguin" role instead of "maintainer". Script can then properly ignore penguin chiefs only when they are referenced as such ("THE REST" case) while still listing the same author when listed as a role maintainer.
At the end, penguin chiefs may even be listed only in MAINTAINERS file, either as today (special S: changing role of M:) or using a dedicated letter (allowing maintainer/chief mix within a section). Script options --git-chief-penguins and --no-git-chief-penguins would then only parse and ignore matching chiefs inside MAINTAINERS, and script array @penguin_chief would disappear.
My feeling is that this would be the cleaner way to address this issue. What is you opinion?
Aside note for curious readers: I actually saw this issue within U-Boot, where Tom Rini (hard-coded penguin chief) is also maintainer of some sections for which get_maintainer.pl does now work as expected.
Regards,
Anthony
On Wed, 2024-01-03 at 16:12 +0000, Anthony LOISEAU wrote:
> Hello,
Hello Anthony.
> I am a little bit cluttered about a few things around
> get_maintainer.pl and the fact that penguin chiefs may also be
> maintainers, at least in third party projects also using
> get_maintainer.pl script. My feeling is that get_maintainer.pl
> mishandles penguin chiefs without it being an issue for Linux case,
[]
> My feeling is that this would be the cleaner way to address this
> issue. What is you opinion?mmm
For the various modified versions of get_maintainer.pl
for other projects, any change should be made there.
I think the linux specific get_maintainer.pl works as-is
and does not particularly need modification.
An option might be to externalize the 'penguin-chief'
block into something like a separate file that is parsed
at initialization.
Maybe with a rename as penguin_chief is generally Tux,
umm Torvalds...