linux-kernel - Re: [PATCH] [RFC] get_maintainer.pl: only list maintainers by default

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4BE66FE1.3010608@s5r6.in-berlin.de>
Date:	Sun, 09 May 2010 10:18:41 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Joe Perches <joe@...ches.com>
CC:	florian@...kler.org, Andrew Morton <akpm@...ux-foundation.org>,
	Stephen Hemminger <shemminger@...tta.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [RFC] get_maintainer.pl: only list maintainers by default

Joe Perches wrote:
> On Sun, 2010-05-09 at 02:22 +0200, Stefan Richter wrote:
>> But how does this indicate a need to include these addresses into
>> get_maintainer.pl output?  In no way at all.
> 
> Supporting stats please.
> 
> I gave you some that seem to differ from your
> position.

What do want with statistics here?  Look at semantics, not at
quantities.  Look at what this thread started.

You apparently overlooked what I wrote earlier, so I repeat it to be sure:

>>>
$ git log fs/eventpoll.c include/linux/wait.h |grep stefanr
    Reported-by: Stefan Richter <stefanr@...6.in-berlin.de>
    Tested-by: Stefan Richter <stefanr@...6.in-berlin.de>

Please do not Cc me on subsystems that I do not develop nor maintain.
My personal inbox is full enough and my todo-list growing.
When I have time to look at patches to subsystems that I don't work with
normally, I look into my inbox.lkml.

If you rely on scripts/get_maintainer.pl, then please use it more
carefully or improve the script to produce more qualified Cc lists.

Thanks.
<<<

>>>
Cc'ing a
reporter or tester would only make sense if the patch changes something
that directly affects the reporter's/ tester's setup, e.g. reworks a
provisional fix.
<<<
[which is highly unlikely, and in those special cases get_maintainer.pl
is not where we take that info from]

>>>
  - Reported-by: and Tested-by: signed commits were most likely about
    something radically different from what the new patch submission is
    about.
<<<

But wait, you want stats, you get stats.
  $ git log drivers/firewire/ drivers/ieee1394/ |
    grep -e "Tested-by: " -e "Reported-by: "
lists 32 people of whom
  - 0 need to be/ should be included in the address list of a patch
    submission,
  - 2 or 3 were active in firewire subsystem development (but not
    anymore) but were perfectly fine to reach via MAINTAINERS' L: entry
  - 3 or 2 are still somewhat involved in firewire subsystem
    development, but only in special application domains, and they are
    reached via MAINTAINERS' L: entry

You on the other had found e.g. Ingo among testers signatures.  Could
you show a single source file of which a patch should be Cc'd to Ingo
and get_maintainer.pl finds him only among testers or reporters but no
among the MAINTAINERS M: entries nor among the signed-off-bys?  (Or any
of the other maintainers that you found.)
-- 
Stefan Richter
-=====-==-=- -=-= -=--=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/