[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1hbhucdv5.fsf@fess.ebiederm.org>
Date: Mon, 13 Sep 2010 00:16:30 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Florian Mickler <florian@...kler.org>
Cc: Christoph Hellwig <hch@...radead.org>,
Joe Perches <joe@...ches.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"Stephen Hemminger \(role\:commit_signer\)" <shemminger@...tta.com>,
"Wolfram Sang \(role\:commit_signer\)" <w.sang@...gutronix.de>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] get_maintainer.pl: append reason for cc to the name by default
Florian Mickler <florian@...kler.org> writes:
> On Fri, 10 Sep 2010 20:45:51 -0400
> Christoph Hellwig <hch@...radead.org> wrote:
>
>> On Fri, Sep 10, 2010 at 05:31:14PM -0700, Joe Perches wrote:
>> > If you don't like it, you could use a .get_maintainer.conf
>> > file entry until some consensus is reached later.
>>
>> I don't use the pice of junk at all. What really pisses me off is that
>> I get spamed by all by tons of utterly useless cleanups patches (and
>> some useful but not at all interesting to me patches) because some
>> idiot made the bloody script return my address just because I touched a
>> file. If it goes on like that I'll simply have to add a mail filter to
>> throw away all patches sent directly to me instead of a mailinglist.
>>
>
> But would you also have the same attitude towards these specific
> 'spams' if it were made clear in the email adress field that you were
> cc'd as a commit_signer (vs maintainer)?
>
> I know it is a bit hackisch to have stuff in the name field, but it is
> rfc conform, it is even proposed for redirected email '(by way
> of...)'.
It is trivial for a human to look at a git log and see which changes
were just global cleanups and which changes were actual maintenance.
Apparently get_maintainers doesn't have that ability.
Have seen some files with something like 5 years of changes without a
single commit by a maintainer and the only changes happening to it are
global cleanup changes.
If get_maintainers would look at MAINTAINERS and validate or invalidate
that information by looking at git that would be useful.
If get_maintainers can't validate what in MAINTAINERS perhaps it can
suggest that the author read the git log to get an idea of who has been
working on the code lately.
I guess what would be very good would be if get_maintainers would
present the information from the git log not as a fact but instead as a
guess. Presenting people who only made a single change to a file on
equal footing with people were involved with 95% of the changes to a
file gets silly.
For people who have just a few commits in a file I expect presenting the
commit id's and subject lines of the patches they have touched so a
person with a brain can easily filter out the nonsense hits would be
very useful.
At this point I agree with Christoph being CC'd on every mips syscall
change on every architecture for the rest of my life because
get_maintainers.pl is too stupid to even indicate to the user of the
script that it might have made a mistake is silly.
Adding an "ignore me" tag to email addresses generated by
get_maintainer.pl would only encourage people to filter those emails
when they get them, which is not what we want. Let's see if we can make
the script smart enough so people sending patches can use their own
intelligence to keep from asking people to look at things that they have
utterly no interest in.
This whole thing reminds me of a quote my father used to have hanging
in his study: "To err is human. To really foul things up use a computer"
Eric
--
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/
Powered by blists - more mailing lists