在 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