From: Markus Armbruster <armbru@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] get_maintainer.pl: Default to --no-git-fallback
Date: Tue, 21 Oct 2014 11:31:12 +0200 [thread overview]
Message-ID: <87vbnddb1b.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <20141020190358.GA12441@redhat.com> (Michael S. Tsirkin's message of "Mon, 20 Oct 2014 22:03:58 +0300")
"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Mon, Oct 20, 2014 at 03:19:52PM +0100, Peter Maydell wrote:
>> On 20 October 2014 15:15, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > On Mon, Oct 20, 2014 at 03:04:44PM +0100, Peter Maydell wrote:
>> >> On 20 October 2014 10:19, Markus Armbruster <armbru@redhat.com> wrote:
>> >> > Contributors rely on this script to find maintainers to copy. The
>> >> > script falls back to git when no exact MAINTAINERS pattern matches.
>> >> > When that happens, recent contributors get copied, which tends not be
>> >> > particularly useful. Some contributors find it even annoying.
>> >> >
>> >> > Flip the default to "don't fall back to git". Use --git-fallback to
>> >> > ask it to fall back to git.
>>
>> >> Good idea.
>>
>> > What do you want to happen in this case?
>>
>> It should mail the people who are actually maintainers,
>> not anybody who happened to touch the code in the last
>> year.
>
> Right but as often as not there's no data about that
> in MAINTAINERS.
The way to fix that is finding maintainers, not scatter-shooting patches
to random contributors in the vague hope of hitting someone who cares.
>> > I'm yet to see contributors who are annoyed but we
>> > can always blacklist specific people.
>>
>> At the moment I just don't use get_maintainers.pl at
>> all because I tried it a few times and it just cc'd
>> a bunch of irrelevant people...
>>
>> I suspect anybody using it at the moment is either
>> using the --no-git-fallback flag or trimming the
>> cc list a lot.
>>
>> thanks
>> -- PMM
>
> I'm using it: sometimes with --no-git-fallback, sometimes without.
I'm using it, but I absolutely want to know when it falls back to git,
because then I want to cheack and trim or ignore its output every single
time.
> IIUC the default is to have up to 5 people on the Cc list
> (--git-max-maintainers).
> It's not like it adds 200 random people, is it?
>
> Anyway experienced contributors can figure it out IMHO.
Experienced contributors can figure out --git-fallback, too.
What we see is contributors, especially less experienced ones, copying
whatever get_maintainers.pl spits out, because they have no idea what
get_maintainers.pl actually does.
> Question in my mind is what do we want a casual contributor
> to do if there's no one listed in MAINTAINERS.
> "Look in MAINTAINERS, if not there, look in git log"
> sounds very reasonable to me, better than "CC no one".
But that's not what we do! We do "copy whatever get_maintainers.pl
coughs up", which boils down to "use MAINTAINERS, if not there, grab
some random victims from git-log".
Perhaps we'd get slightly better results if get_maintainers.pl told its
users clearly about the two kinds of output it may produce: maintainers
(must be copied on patches), and recent contributors (you're in trouble;
copying some of them may or may not help).
next prev parent reply other threads:[~2014-10-21 9:31 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-20 9:19 [Qemu-devel] [PATCH] get_maintainer.pl: Default to --no-git-fallback Markus Armbruster
2014-10-20 12:27 ` Don Slutz
2014-10-20 14:04 ` Peter Maydell
2014-10-20 14:15 ` Michael S. Tsirkin
2014-10-20 14:19 ` Peter Maydell
2014-10-20 19:03 ` Michael S. Tsirkin
2014-10-20 20:10 ` Don Slutz
2014-10-20 21:07 ` Peter Maydell
2014-10-21 9:31 ` Markus Armbruster [this message]
2014-10-21 10:00 ` Michael S. Tsirkin
2014-10-21 12:22 ` Markus Armbruster
2014-10-21 12:38 ` Michael S. Tsirkin
2014-10-21 13:29 ` Markus Armbruster
2014-10-21 22:30 ` Michael S. Tsirkin
2014-10-22 6:39 ` Markus Armbruster
2014-10-22 7:01 ` Michael S. Tsirkin
2014-10-22 8:10 ` Thomas Huth
2014-10-22 8:18 ` Michael S. Tsirkin
2014-10-20 18:38 ` Paolo Bonzini
2014-10-21 11:09 ` Gerd Hoffmann
2014-10-21 11:15 ` Michael S. Tsirkin
2014-10-21 11:23 ` Gerd Hoffmann
2014-10-21 11:35 ` Michael S. Tsirkin
2014-10-21 13:34 ` Markus Armbruster
2014-10-21 13:39 ` Paolo Bonzini
2014-10-21 13:46 ` Kirill Batuzov
2014-10-21 22:31 ` Michael S. Tsirkin
2014-10-22 7:01 ` Markus Armbruster
2014-10-22 7:12 ` Michael S. Tsirkin
2014-10-22 7:45 ` Paolo Bonzini
2014-10-22 8:03 ` Markus Armbruster
2014-10-22 8:29 ` Michael S. Tsirkin
2014-10-22 19:25 ` Don Slutz
2014-10-21 6:22 ` Thomas Huth
2014-10-21 9:19 ` Markus Armbruster
2014-10-21 13:40 ` Kirill Batuzov
2014-10-21 14:15 ` Markus Armbruster
2014-10-21 22:35 ` Michael S. Tsirkin
2014-10-20 15:06 ` Eric Blake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vbnddb1b.fsf@blackfin.pond.sub.org \
--to=armbru@redhat.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.