qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] finally kill cpudef config section support


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH] finally kill cpudef config section support
Date: Sun, 09 Dec 2012 20:13:36 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

Am 08.12.2012 21:00, schrieb Blue Swirl:
> On Sat, Dec 8, 2012 at 6:02 PM, Andreas Färber <address@hidden> 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.

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.

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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]