On Fri, Jan 31, 2014 at 12:30:17PM +0100, Andreas Färber wrote:
Am 30.01.2014 22:47, schrieb Paolo Bonzini:
> Il 30/01/2014 20:48, Eduardo Habkost ha scritto:
>> Is there any hope to get this into QEMU 2.0, or it is now too late? I got
>> almost no feedback on take 6 (submitted November 27).
>
> It's not too late, not for me at least. I wanted to send the next
> uq/master pull request tomorrow or Tuesday, after I've done some more
> testing on enlightenments. I can squeeze this in too.
Negative, not without my review. It's clearly a CPU series, and apart
from having been on vacation pretty much all of December, Eduardo and
others have objected to my subclass series the last 2 *years*, so 2
months is peanuts by comparison.
I don't remember objecting to your approach, but we simply had lots of
details to understand and questions settle. Then in February we
(Andreas, Igor, and me) stopped submitting new versions while we focused
in other stuff.
I was also not aware how the lack of subclasses would badly affect
libvirt's ability to use the new QOM properties we have added. I only
noticed that while talking to Jiri last November, that's why I resumed
the subclass work after months, to try to get it into QEMU 2.0.
Further, I was under the impression that this series depends on Igor's
feature property series, which I haven't found time to rework and
haven't noticed anyone else do either. So if there's no prereqs (why
uq/master?) I'll happily start reviewing and queuing it.
It doesn't depend on the feature properties at all.
But the series is based on uq/master only because it depends on
KVM-specific patches that are already on uq/master (that's why I added
uq/master to the Subject. It doesn't mean it has to be pulled through
uq/master necessarily).
As Eduardo points out below the commit message in the final patch, his
conversion is very similar to one of my earlier patch series, so
committing that with Eduardo as author via uq/master without crediting
me via uq/master would leave a bad taste.
Sorry, what would be the proper way to give proper attribution on the
commit message in this case? I often don't know if it is appropriate to
keep a Signed-off-by line if most of the code is new.
Also, I was incorrectly assuming the whole patch was re-written from
scratch by me, but now I have noticed I have copied
x86_cpu_list_compare() (and other parts) from your code without proper
attribution, I am very sorry for that. My poor excuse is that I have 3
or 4 local git branches where I was experimenting with different
approaches, and it was hard to keep track of everything.
--
Eduardo