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