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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
