Re: [Qemu-devel] [PATCH 11/13] Move pci_parse_devaddr to qdev-properties

[Jan Kiszka]

On 2012-06-08 14:03, Andreas Färber wrote:
> Am 08.06.2012 12:57, schrieb Jan Kiszka:
>> On 2012-06-07 17:56, Andreas Färber wrote:
>>> Am 07.06.2012 17:11, schrieb Jan Kiszka:
>>>> On 2012-06-07 14:57, Andreas Färber wrote:
>>>>> These last three patches collide with Paolo's QOM properties 
>>>>> refactoring: qdev properties are being generalized to Object and
>>>>> on my GitHub "realize" branch are being moved to
>>>>> qom/object-properties.c (object.c in the original series). Please
>>>>> defer this change.
>>>
>>>> Depends on how long merging of those branches shall take. This is
>>>> some important piece for preparing device assignment for upstream,
>>>> thus finally closing the qemu-kvm fork. I need all this back-merged
>>>> in qemu-kvm soon to proceed.
>>>
>>>> Can you (both) comment on the merge schedule for your patches? Are
>>>> we talking about a week or so?
>>>
>>> I'm working towards sending the updated patches from realize branch
>>> today and the PULL by tomorrow. When it gets merged I cannot predict.
>>
>> To my understanding, patch 2 of your series faces some discussions, and
>> the rest will require refactoring once that has settled. So I guess it's
>> better now to proceed with my patches and rebase your changes on top of
>> them, right?
> 
> No, there's a patch queue of 28 before the patches under discussion,
> some of which touch qdev-properties.c as well. Those under discussion
> are not on qom-next yet.
> What's open is that the Makefile series has not been pulled yet and
> pretty much everyone will need to rebase on that if it gets applied.
> Hoping for a statement from Anthony there.

As I was on CC in that second series, right after you told me you would
CC me to allow tracking progress. So I was assuming it was related to
this topic.

> 
> Can't understand that you're trying to push your v1 so hard now when our
> series have been on the list for much longer. ;)

I explained the reason, and I think my patches (minus the dropped one)
are ready based on the feedback.

I'm fine if important central refactorings close master for a short
period at the beginning of a merge window and require rebasing of other
patches afterward. But that should really be *short*.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux