From: George Dunlap <george.dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Jacob Shin <jacob.shin@amd.com>,
Xiantao Zhang <xiantao.zhang@intel.com>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 1/4] IOMMU: allow MSI message to IRTE propagation to fail
Date: Thu, 28 Mar 2013 10:33:43 +0000 [thread overview]
Message-ID: <51541C87.4020709@eu.citrix.com> (raw)
In-Reply-To: <51540C8702000078000C91D7@nat28.tlf.novell.com>
On 28/03/13 08:25, Jan Beulich wrote:
>>>> On 27.03.13 at 15:55, George Dunlap <george.dunlap@eu.citrix.com> 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.
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@suse.com>" 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).
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.
Thanks,
-George
next prev parent reply other threads:[~2013-03-28 10:33 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-26 8:51 [PATCH 0/4] x86/IOMMU: multi-vector MSI prerequisites Jan Beulich
2013-03-26 9:03 ` [PATCH 1/4] IOMMU: allow MSI message to IRTE propagation to fail Jan Beulich
2013-03-27 11:45 ` George Dunlap
2013-03-27 12:16 ` Jan Beulich
2013-03-27 14:45 ` Boris Ostrovsky
2013-03-27 14:55 ` George Dunlap
2013-03-28 8:25 ` Jan Beulich
2013-03-28 9:46 ` Tim Deegan
2013-03-28 9:49 ` George Dunlap
2013-03-28 10:33 ` George Dunlap [this message]
2013-03-28 11:14 ` Jan Beulich
2013-03-28 11:25 ` Tim Deegan
2013-03-28 11:39 ` George Dunlap
2013-03-28 13:47 ` Stefano Stabellini
2013-05-06 20:25 ` Is: git send-email, patch sending, etc Was: " Konrad Rzeszutek Wilk
2013-05-07 8:53 ` Ian Campbell
2013-05-07 9:26 ` Wei Liu
2013-05-07 14:03 ` Konrad Rzeszutek Wilk
2013-03-27 17:26 ` George Dunlap
2013-03-28 8:27 ` Jan Beulich
2013-03-26 9:03 ` [PATCH 2/4] x86/MSI: cleanup to prepare for multi-vector MSI Jan Beulich
2013-03-26 9:04 ` [PATCH 3/4] AMD IOMMU: allocate IRTE entries instead of using a static mapping Jan Beulich
2013-04-02 8:38 ` [PATCH v2 " Jan Beulich
2013-04-11 0:34 ` Suravee Suthikulpanit
2013-03-26 9:05 ` [PATCH 4/4] AMD IOMMU: untie remap and vector maps Jan Beulich
2013-03-28 12:37 ` George Dunlap
2013-03-28 13:09 ` Jan Beulich
2013-03-28 13:40 ` George Dunlap
2013-03-29 5:18 ` [PATCH 0/4] x86/IOMMU: multi-vector MSI prerequisites Suravee Suthikulpanit
2013-03-29 5:45 ` Suravee Suthikulpanit
2013-04-02 8:39 ` Jan Beulich
2013-04-10 13:55 ` Jan Beulich
2013-04-10 14:38 ` Suravee Suthikulanit
2013-04-10 14:46 ` Jan Beulich
2013-04-11 1:51 ` Suravee Suthikulpanit
2013-04-11 7:13 ` Jan Beulich
2013-04-11 15:40 ` suravee suthikulpanit
2013-04-11 16:11 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51541C87.4020709@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=jacob.shin@amd.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=xen-devel@lists.xen.org \
--cc=xiantao.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).