On Sun, Dec 9, 2012 at 7:13 PM, Andreas Färber <afaer...@suse.de> wrote: > Am 08.12.2012 21:00, schrieb Blue Swirl: >> On Sat, Dec 8, 2012 at 6:02 PM, Andreas Färber <afaer...@suse.de> wrote: >>> Am 08.12.2012 18:54, schrieb Blue Swirl: >>>> Thanks, applied. >>> >>> As discussed this still leaves some cpudef cruft behind. >> >> But Eduardo said that it will be removed later. > > I chose not to include it in the current qom-cpu pull while I was still > investigating how to resolve the conflict between the patch claiming to > "finally kill", not satisfactorily doing it but not yet having X86CPU > subclasses. > > Actually I now found a very easy and un-intrusive way to clean that up, > series coming up! > > What I am disappointed about here is the work duplication. The only user > of this cpudef is the x86 CPU, an area that I have been maintaining > since Anthony asked for help with his maintenance areas. You can argue > that qemu-config.c is not under my maintenance and that > target-i386/cpu.c is not properly documented as such in MAINTAINERS > (which I will fix, noticing this), but either way since my reply > indicates that I started review, I would have appreciated a reply > indicating you agree with Eduardo I should apply it as such or asking > whether you can apply it now rather than applying this patch without > anyone's Reviewed-by or Acked-by while my pull is still in flight.
Actually I checked that it didn't conflict with your pull (which I applied) and also with your RFC series (which I didn't apply, of course). So it looked OK to me. > Generally I expect committers to handle PULLs from maintainers and > PATCHes from unmaintained areas only. At times in lack of communication > those borders get blurred, leading to patches handled differently by two > persons, such as the Haswell patch showing up twice in the shortlog or > this patch getting applied while review comments are unresolved. > > If you think I'm doing a terrible job as maintainer (hard freeze, review > times, my perfectionism...) and wish to handle x86 CPU patches yourself, > just say so openly and I'll happily invest my time in an area where the > effort is more appreciated. I think you are doing a great job, thanks for your efforts. I have no interest for doing the QOM conversion myself. > What I would've liked was an idea raised at QEMU Summit of having a > staging tree similar to the trivial queue as sort-of a last-call to > point out typos or potential conflicts between trees before a patch > lands in qemu.git and either stays or must be reverted or followed up. > But this did not find a lot of support. I think it would be nice if you could take patches like this which are close to your CPU patches and keep them in your tree, or just NAK patches which conflict with other work. That kind of coordination would avoid staging problems. What's for example the plan for Igor's series, should they be applied next or something else? > > Regards, > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
