On Wed, 2013-06-26 at 12:58 +0000, KY Srinivasan wrote: > > > -----Original Message----- > > From: KY Srinivasan > > Sent: Monday, June 17, 2013 9:32 AM > > To: gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > > devel@xxxxxxxxxxxxxxxxxxxxxx; ohering@xxxxxxxx; jbottomley@xxxxxxxxxxxxx; > > hch@xxxxxxxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx > > Subject: RE: [PATCH V3 0/5] Drivers: scsi: storvsc > > > > > > > > > -----Original Message----- > > > From: KY Srinivasan > > > Sent: Tuesday, June 11, 2013 9:02 AM > > > To: KY Srinivasan; gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > > > devel@xxxxxxxxxxxxxxxxxxxxxx; ohering@xxxxxxxx; jbottomley@xxxxxxxxxxxxx; > > > hch@xxxxxxxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx > > > Subject: RE: [PATCH V3 0/5] Drivers: scsi: storvsc > > > > > > > > > > > > > -----Original Message----- > > > > From: K. Y. Srinivasan [mailto:kys@xxxxxxxxxxxxx] > > > > Sent: Tuesday, June 04, 2013 3:05 PM > > > > To: gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > > > > devel@xxxxxxxxxxxxxxxxxxxxxx; ohering@xxxxxxxx; > > jbottomley@xxxxxxxxxxxxx; > > > > hch@xxxxxxxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx > > > > Cc: KY Srinivasan > > > > Subject: [PATCH V3 0/5] Drivers: scsi: storvsc > > > > > > > > This set adds multi-channel support as well synthetic Fibre Channel support > > > > to storvsc. The multi-channel support depends on infrastructure in the > > VMBUS > > > > driver. Greg has already checked in the relevant patches to VMBUS. > > > > > > > > I had posted an earlier version of this patch-set that included the VMBUS > > > > related changes. I have since separated the VMBUS chages and these have > > > > already been > > > > checked in. > > > > > > > > In this version, based on comments from James, the timeout is no longer a > > > > module > > > > parameter. > > > > > > James, > > > > > > I think I have addressed all the comments that you had; if not, please let me > > > know. > > > > Ping. > > James, > > Let me know if I should re-send the patches. Just FYI, my workflow involves using imap flags to tag stuff for actions and then using a set of date sorted evolution search folders to translate the flags into work queues. The search folders are by flag and thread, so a side effect of the way evolution does date ordering is that it's ordered by the most recent last, so the date it takes for thread ordering is the most recent email in the thread. Originally, I thought of this as an annyoing evolution bug because I wanted the folder ordered by date of the patch submission. However, later I came to appreciate that it meant currently actively discussed patches moved down in my workqueue automatically, so now I quite like it as a feature. It does mean, however, that the net effect of sending very frequent pings about a patch set is to cause that patch set to move down in my work queue and, unfortunately, even coming from a domain that habitually breaks threading doesn't save you because evolution helpfully has a set of heuristic rules to rethread outlook breakage. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
