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
