Re: [PATCH V3 0/5] Drivers: scsi: storvsc

[James Bottomley]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/