qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: qemu: tree for pci related fixes


From: Michael S. Tsirkin
Subject: [Qemu-devel] Re: qemu: tree for pci related fixes
Date: Thu, 24 Sep 2009 07:41:15 +0300
User-agent: Mutt/1.5.19 (2009-01-05)

On Wed, Sep 23, 2009 at 01:11:48PM -0500, Anthony Liguori wrote:
> Hi Michael,
>
> Michael S. Tsirkin wrote:
>> Hi!
>> I created a qemu tree to collect pci related qemu fixes,
>> to make sure they don't get lost.
>>
>> The idea's the patches have been posted on list already, so it should be 
>> enough
>> to repost a short summary here, rather than flood everyone's
>> mailboxes by reposting a full patchset.
>>
>> The tree is here:
>> git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci
>>
>> Beware: do not publish a tree on top of this one as I might be rebasing it. 
>> If
>> you want me to add a patch there, just mail me.
>>
>> Below's the first nag:
>>
>> ---
>>
>> Here are the pci fixes I know of that haven't been applied already.
>> Anthony, all, any more comments on any of them?
>> If yes, please reply on the original patch.
>> If no, please apply.
>>
>> 9305505 qemu/virtio-pci: remove unnecessary check
>>   
>
> This was posted yesterday.

Well, it's an obvious one-liner.  Trivial patches can get in
my tree faster than complex ones.  I realize you have a huge queue of patches
to go through so even trivial ones become a burden with
compilation failures and whatnot, but my queue is short :)

>> c128c88 qemu/pci: reset device registers on bus reset
>> 74b7e8b qemu/pci: refactor code/symbolic constants
>> 5307502 qemu/virtio: fix reset with device removal
>> c1f2e99 qemu/qdev: type safety in reset handler
>>   
>
> These were posted a week ago.  I am behind on staging unfortunately.
> 
> I think it makes sense for everyone to keep their own trees and to make  
> them publicly accessible.  However, for resends, I would still like them  
> to occur on the mailing list.
>
> In general, I would wait at least two weeks for a resend.  I understand  
> that this is a very long time and I'm working on trying to make patch  
> response time more reliable.  I would like to point out though that  
> these patches are by no means lost.

Yes, recently I do not remember real need for resends, as in patch being
lost.  That's why I'm sending out a summary instead.  For example, it is
possible that some objection to a patch was not addressed and the author
missed this fact in the latest version.  I'm not trying to say "merge
this now", I'm trying to say "I think it's ready, please shout if it's
not".

>
> Regards,
>
> Anthony Liguori




reply via email to

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