Re: [Qemu-trivial] [PATCH] cputlb: remove dead function tlb_update_dirty

[Li Guang]

在 2013-09-03二的 18:54 +0200，Andreas Färber写道：
> Am 03.09.2013 13:17, schrieb Michael Tokarev:
> > 03.09.2013 12:35, Andreas Färber wrote:
> >> I also don't understand why qemu-trivial is suddenly picking up Stefan's
> >> arm translation patch, it used to be for unmaintained areas only. But
> >> arm is not my problem.
> > 
> > Which patch you're talking about?  Is it "target-arm: Report unimplemented
> > opcodes (LOG_UNIMP)" ?
> 
> Yes.
> 
> >  If yes, that one appears to be trivial as it just
> > adds some logging before failing an instruction and should not conflict
> > with other work being done in this area.  Perhaps I was too aggressive
> > while picking up the backlog.  We should just draw the line *somewhere*, --
> 
> Right, that line is what I'm reminding about here. I feel that lately an
> increasing number of contributors and reviewers are deferring patches to
> qemu-trivial that don't really belong there IMO. That Anthony doesn't
> scale to cover Blue's maintainer work as well shouldn't lead to a surge
> on qemu-trivial.
> 
> > eg, it sure is possible to reject spelling fixes for maintained areas
> > from -trivial (like this arm tree), - will this be productive?
> 
> No, spelling fixes are not a concern to me as they are rather unlikely
> to cause conflicts with patches being queued by submaintainers. :)
> 
> > This change (cputlb: remove dead function) appears to be "trivial enough"
> > for me (after looking at the usage history of this function), and I'd
> > pick it up without this Andreas's request, too.
> 
> Yes. This one here would've been okay usually, as there is no official
> maintainer for cputlb.c and it's trivial in the sense that a git-grep
> confirms it to be okay. I was just annoyed that I had to defer my pull
> twice (sent it out now) because s390x added two CPU loops and then once
> that was merged ppc added another loop, too. My upcoming 35+ patch
> series qom-cpu-13 may hopefully explain the rest once you see it.
> 
> > As for the "suddenly" - it's not really suddenly, it's because it
> > has been Cc'd to -trivial (by someone who submitted lots of good
> > trivial patches before) and actually looks trivial, too.  And also
> > because subsystem maintainer added his Reviewed-by, apparently (or
> > hopefully) after noticing it's submitted to -trivial.  I also Cc'd
> > both maintainers in my notice that it's been applied to -trivial.
> 
> "Suddenly" in the sense that the prupose of qemu-trivial used to be
> handling patches that would otherwise fall through the cracks.
> 
> So by my understanding, e.g., "target-arm:" => !trivial, and I would've
> expected there to be some on-list communication between PMM and you
> before CC'ing someone on a "thanks, applied" after the fact.
> By contrast, if there's a change to configure or "Fix spelling of" etc.
> then you picking it up is highly appreciated. I just don't want
> qemu-trivial becoming the least-resistance way of getting patches into
> qemu.git that might otherwise get bounced/changed by submaintainers.
> 
> Also, I am seeing Paolo pull in huge memory changes but now pinging the
> breakage fixes rather than assembling a pull to fix the fallout. ;)
> 
> Similarly target-i386 TCG is not suited for qemu-trivial IMO, instead
> rth or someone who works on and/or reviews it (rth?) should volunteer as
> proper maintainer. 

 I'd like to maintain cputlb.c, can I?

> With the larger part of the community using KVM these
> days, we simply can't have that be handled by the community at large any
> more.
> 
> So yes, I know you were on vacation and you seem eager to take up work
> again, that's great; I'm just cautioning that CC'ing everything on
> qemu-trivial (not your fault, you're on the receiving end) can't be the
> new solution, so feel encouraged to push back a little. :)
> 
> Cheers,
> Andreas
> 

-- 
Thanks!

Li Guang