Re: [RFC][PATCH] update SubmittingPatches to clarify attachment policy

["Randy.Dunlap" <rddunlap@osdl.org>]

On Wed, 04 May 2005 20:52:45 +0200
Krzysztof Halasa <khc@pm.waw.pl> wrote:

> There is MIME "Content-Disposition: inline".
> Personally I think it's at least as good as plain text - it's MIME
> attachment (you can extract automatically, you have well-defined patch
> boundaries, original file name etc.) _and_ mail readers are supposed to
> (and do) display such attachments as normal message parts.
> 
> The message is readable with MIME-unaware readers (scripts etc.) as well.
> 
> Such attachment (raw message data) looks like:
> 
[snip]
> 
> > +code.  If you must use an attachment,
> 
> > verify that it has no
> > +Content-Type-Encoding.
> 
> Content-Transfer-Encoding.
> 
> I'd say "verify that it's binary-encoded - quoted-printable and base64
> encodings are not permitted".
> 
> I.e., it's perfectly fine to specify "Content-Transfer-Encoding: 7bit"
> (or "8bit" or possibly "binary", though I don't exactly know the
> difference between "8bit" and "binary").
> 
> >  A MIME attachment also takes Linus a bit more
> > +time to process, decreasing the likelihood of your MIME-attached
> > +change being accepted.
> 
> I don't think so. Badly formatted MIME attachments, sure. I'd be
> surprised if Linus applies them at all.
> 
> >  Exception:  If your mailer is mangling patches then someone may ask
> > -you to re-send them using MIME.
> > +you to re-send them compressed or using other MIME encodings.
> 
> Rather: "... someone may ask you to re-send them as properly encoded
> MIME attachments".
> 
> 
> In fact I'd encourage using binary-encoded inlined MIME attachments
> at all times, with non-MIME 7bit or 8bit plain text being accepted
> as secondary format.


A couple of days ago, Matt Mackall described/proposed a tool to
check new patches for acceptable content and format:
  http://www.selenic.com/pipermail/kernel-mentors/2005-May/000072.html

I'm attaching a rudimentary version of such a tool (check-patch.pl).
It does not attempt to check for line wrapping or lines that are
> 80 characters.
It dislikes patches that contain attachments that are base64,
quoted-printable, or binary (e.g.).

People can run this script locally, but ideally We (royal) will
have an email address for it so that people can use it to check
if their mail interface munges the patch for them... :(
and can try again until it doesn't.

Yeah, it's not perfect and it's a bit verbose.
Patches accepted (or even complete rewrites :).

---
~Randy

Attachment: check-patch.pl
Description: Binary data