On Tue, Oct 21, 2014 at 11:31:12AM +0200, Markus Armbruster wrote: > "Michael S. Tsirkin" <m...@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 <m...@redhat.com> wrote: > >> > On Mon, Oct 20, 2014 at 03:04:44PM +0100, Peter Maydell wrote: > >> >> On 20 October 2014 10:19, Markus Armbruster <arm...@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.
Well it tells you the role. What else is necessary? > > 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. Exactly. > 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. Exactly. And this seems better than just sending to qemu ML and not copying anyone. > > 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". Sorry, what's the difference? "look in" versus "random victims"? what makes them random? Maybe you just want to increase git-min-percent? > 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). That's what it does: it reports the role, and the percent. What's missing? -- MST