Re: [Xen-devel] [PATCH 1/4] IOMMU: allow MSI message to IRTE propagation to fail

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.03.13 at 11:33, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> On 28/03/13 08:25, Jan Beulich wrote:
>>>>> On 27.03.13 at 15:55, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
>>> Did you look at the mail in your mailreader, or in the raw mail format?
>> In the mail reader of course (after all I expect you to use a mail
>> client too). And as said, I saw some damage when looking at the
>> copy on lists.xen.org.
>>
>>> If you're using your mail reader, it's probably interpreting the
>>> wordwrap stuff properly.  The "raw" mail looks like this:
>>>
>>> http://marc.info/?l=xen-devel&m=136428861403115&q=raw 
>>>
>>> The above is what GMail sees if I click "show original", and also what
>>> the Citrix mail system gives me if I save the mail as a file. This
>>> mangling is apparently called "quoted-printable":
>>> http://en.wikipedia.org/wiki/Quoted-printable 
>>>
>>> The problem is that "patch" (and thus "git apply", "git am", "hg
>>> import", &c &c), not being a mail-reader, doesn't know how to de-mangle
>>> stuff.
>> And rightly so. But your mail client saving the mail should deal with
>> this properly. (And besides, if you already save the mail, I don't
>> see why you can't instead save the attachment).
> 
> This is already a longer discussion than I really wanted to have, but 
> just so you have an idea what I'm on about, I'll explain the difference.
> 
> The key thing is that "git am" will take an mbox file with a series of 
> patches and automatically make a commit for each one.  So my algorithm 
> for reviewing patch series sent in text/plain is as follows:
> 
> 1. In Gmail, mark each patch in the series and save it to a special folder.

And in that operation, the quoted printable encoding should be
undone. Which makes all of the rest of your mail more or less
mute.

> 2. Open up mutt on my local box.  It will connect to gmail and open that 
> folder.
> 3. Mark each patch in the series and save it to a local folder in ~/mail/.
> 4. Use git am to import the whole series as a sequence of commits.
> 5. View the changeset "in situ" using various git commands ('git meld' 
> is my favorite ATM).
> 
> Marking each one might take 10 seconds, and it's almost entirely 
> brainless; the main "cognitive load" is just remembering the name that 
> I've given the local mail folder.  A series of 40 patches takes 
> basically no more cognitive load to download and import into my git tree 
> than a single patch.
> 
> To view yours at the moment, I have to do the following:
> 1. For each patch in the series, click to download the attachment and 
> save it to a separate file
> 2. Edit each file to include "From: Jan Beulich <JBeulich@xxxxxxxx>" at 
> the top, so it looks sufficiently like an mbox that "git am" won't complain
> 3. For each patch in the series, run "git am" on it individually.
> 
> So #1 is slightly more annoying, as saving is more like 2 seconds per 
> mail and marking a message is like 0.5 seconds per mail.  But the big 
> source of cognitive load is having to deal with the different name of 
> each patch.  It's just that extra little bit when having to open the 
> file to add the header, and particularly then having to figure out what 
> order the patches go in.  It doesn't really take that much extra time, 
> but that it takes attention to remember the filename, and this adds up 
> for each patch in the series; so the longer the series, the more 
> cognitive load it generates.
> 
> They've done studies that show that even a minimal amount of cognitive 
> load has an effect on people's endurance for other cognitive 
> activities.  This is why most successful people instinctively find a way 
> to make the unimportant decisions in their lives really simple -- 
> spending time thinking about what to wear or what to eat eats away at 
> precious energy they would rather spend on running the country or 
> whatever it is they're doing.
> 
> Given the limited amount of head-space I have for arbitrary strings of 
> things, I'd prefer to spend it on actually understanding the patch, 
> rather than on patch filenames if I can avoid it; that's why I brought 
> it up.
> 
> It seems like having an automated way to send off an entire patch queue, 
> rather than cutting and pasting and attaching each mail individually, 
> would reduce the cognitive load for you as well (not to mention probably 
> save you several minutes of your day).  git and mercurial both have 
> really good integrated mechanisms to do that; both also have extensions 
> that allow you interact with the repository just like you do with 
> quilt.  I'm not familiar with the git ones, but the mercurial one uses 
> almost exactly the same commands as quilt, but with "hg" instead of 
> "quilt" at the front (if I remember quilt correctly -- it's been a long 
> time since I used it).

Indeed this might save me some time when sending the patches.
But would it not require more time when fiddling with the patches
while putting them together? As an example, I don't normally
write patch descriptions right away, but do so only when getting
ready to submit the patches. With git wanting to create a commit
out of everything, I have to then run extra git commands to get
the description added to each patch. Whereas with quilt this is a
simple editing of the patch file, easily cut-n-paste between
different instances of the patch on different trees (which I
particularly find myself in need of when producing security fixes
and their backports).

Similarly, fixing minor issues (including rejects because of changes
to earlier files in the series) by editing a patch file is impossible
with git afaict. And no, using git's merge functionality is of no
help to me at all, not the least because of the close to unusable
(to me at least) UIs of any Linux based editors I've come across
so far. Yet if anything, a merge tool ought to be interactive.
Merges that just leave awful marks in the merge output are
pretty pointless imo.

> If you're not willing to find a way to send it text/plain, could you 
> maybe at least name the attachments "01-[whatever].patch" 
> "02-[whatever].patch"?  I think that would help reduce the cognitive 
> load quite a bit.

That would be possible, but making the patch mail composition
more tedious for me. And while I'm all in favor of making others'
work easier looking at stuff I'm interested in getting reviewed, I
have some difficulty justifying my own effort needing to further
increase to do so. If there was a way to make your and my life
easier in this regard...

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel