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

["Andreas Färber" <afaerber@suse.de>]

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. 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

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg