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

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

[Dave Hansen]

I think the general opinion of posting patches as attachments
has changed over the last few years.  Mailers have been getting
a lot better at handling them, even quoting non-message-body
plain/text attachments in replies.  

Plus, a plain/text attachment message saved to a file can go
into 'patch' the same way that an inline one can.

Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
---

 memhotplug-dave/Documentation/SubmittingPatches |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff -L Documentation/Submitting -puN /dev/null /dev/null
diff -puN Documentation/SubmittingPatches~submitting-patches Documentation/SubmittingPatches
--- memhotplug/Documentation/SubmittingPatches~submitting-patches	2005-05-04 08:07:25.000000000 -0700
+++ memhotplug-dave/Documentation/SubmittingPatches	2005-05-04 09:11:27.000000000 -0700
@@ -181,17 +181,24 @@ patches. Trivial patches must qualify fo
 
 
 
-6) No MIME, no links, no compression, no attachments.  Just plain text.
+6) No MIME, no links, no compression.  Just plain text.
 
 Linus and other kernel developers need to be able to read and comment
 on the changes you are submitting.  It is important for a kernel
 developer to be able to "quote" your changes, using standard e-mail
 tools, so that they may comment on specific portions of your code.
 
-For this reason, all patches should be submitting e-mail "inline".
+For this reason, the preferred way of submitting patches in e-mail is
+"inline", in the same part of the message with everything else.
 WARNING:  Be wary of your editor's word-wrap corrupting your patch,
 if you choose to cut-n-paste your patch.
 
+Many maintainers will now accept patches submitted to them as
+text/plain attachments.  Many mailers quote these attachements in the
+same way that they do for inline patches.  But, some maintainers still
+prefer inlines and they are certainly the safest bet.  In any case,
+never attach more than one patch to a single e-mail.
+
 Do not attach the patch as a MIME attachment, compressed or not.
 Many popular e-mail applications will not always transmit a MIME
 attachment as plain text, making it impossible to comment on your
_

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

[Jon Smirl]

On 5/4/05, Dave Hansen <haveblue@us.ibm.com> wrote:
> 
> I think the general opinion of posting patches as attachments
> has changed over the last few years.  Mailers have been getting
> a lot better at handling them, even quoting non-message-body
> plain/text attachments in replies.

There is also the problem of things like gmail/yahoo where you can't
control the word wrapping.  The only way to submit patches from those
services is as an plain text attachment. If you try to submit then
in-line and they wrap wrong you will collect a lot of hate mail from
Andrew.

-- 
Jon Smirl
jonsmirl@gmail.com

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

[Jan-Benedict Glaw]

On Wed, 2005-05-04 13:10:35 -0400, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 5/4/05, Dave Hansen <haveblue@us.ibm.com> wrote:
> > 
> > I think the general opinion of posting patches as attachments
> > has changed over the last few years.  Mailers have been getting
> > a lot better at handling them, even quoting non-message-body
> > plain/text attachments in replies.
> 
> There is also the problem of things like gmail/yahoo where you can't
> control the word wrapping.  The only way to submit patches from those
> services is as an plain text attachment. If you try to submit then
> in-line and they wrap wrong you will collect a lot of hate mail from
> Andrew.

Well, why should someone use a broken mail service at all?

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

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

[Richard B. Johnson]

On Wed, 4 May 2005, Jan-Benedict Glaw wrote:

> On Wed, 2005-05-04 13:10:35 -0400, Jon Smirl <jonsmirl@gmail.com> wrote:
>> On 5/4/05, Dave Hansen <haveblue@us.ibm.com> wrote:
>>>
>>> I think the general opinion of posting patches as attachments
>>> has changed over the last few years.  Mailers have been getting
>>> a lot better at handling them, even quoting non-message-body
>>> plain/text attachments in replies.
>>
>> There is also the problem of things like gmail/yahoo where you can't
>> control the word wrapping.  The only way to submit patches from those
>> services is as an plain text attachment. If you try to submit then
>> in-line and they wrap wrong you will collect a lot of hate mail from
>> Andrew.
>
> Well, why should someone use a broken mail service at all?
>
> MfG, JBG

Because the net Nazis make often make it the only way to send/receive
mail in a domain. There is nothing coming or going here that doesn't
go through a M$ mail-killer that even saves every thread of evidence.

For instance, there is no signature on this file. I'll bet that
by the time you read it, there is one.

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

[Jan-Benedict Glaw]

On Wed, 2005-05-04 14:23:36 -0400, Richard B. Johnson <linux-os@analogic.com> wrote:
> On Wed, 4 May 2005, Jan-Benedict Glaw wrote:

> >Well, why should someone use a broken mail service at all?
> 
> Because the net Nazis make often make it the only way to send/receive
> mail in a domain. There is nothing coming or going here that doesn't
> go through a M$ mail-killer that even saves every thread of evidence.

No way to send emails with a locally installed email client? There are
so many, even for Windows. ...and I guess quite some of those can be
configured to produce real emails, not only bullshit...

> For instance, there is no signature on this file. I'll bet that
> by the time you read it, there is one.

Nope, your email was fine. No extra crap like copyright/property
disclaimers and the like.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

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

[Lee Revell]

On Thu, 2005-05-05 at 10:12 +0200, Jan-Benedict Glaw wrote:
> On Wed, 2005-05-04 14:23:36 -0400, Richard B. Johnson <linux-os@analogic.com> wrote:
> > On Wed, 4 May 2005, Jan-Benedict Glaw wrote:
> 
> > >Well, why should someone use a broken mail service at all?
> > 
> > Because the net Nazis make often make it the only way to send/receive
> > mail in a domain. There is nothing coming or going here that doesn't
> > go through a M$ mail-killer that even saves every thread of evidence.
> 
> No way to send emails with a locally installed email client? There are
> so many, even for Windows. ...and I guess quite some of those can be
> configured to produce real emails, not only bullshit...

Hell no.  You think any sane admin is going to let every workstation on
the corporate network make outgoing port 25 connections to wherever they
want?

Lee

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

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

On Thu, 2005-05-05 12:43:39 -0400, Lee Revell <rlrevell@joe-job.com> wrote:
> On Thu, 2005-05-05 at 10:12 +0200, Jan-Benedict Glaw wrote:

> > No way to send emails with a locally installed email client? There are
> > so many, even for Windows. ...and I guess quite some of those can be
> > configured to produce real emails, not only bullshit...
> 
> Hell no.  You think any sane admin is going to let every workstation on
> the corporate network make outgoing port 25 connections to wherever they
> want?

Well, in most companies (at least those that have a central internet
connection), people *can* send emails in one way or the other... Really,
I don't see the problem. If you cannot send emails from your company,
hell, then do it at home or from an internet café.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Rafael J. Wysocki]

Hi,

On Wednesday, 4 of May 2005 19:10, Jon Smirl wrote:
> On 5/4/05, Dave Hansen <haveblue@us.ibm.com> wrote:
> > 
> > I think the general opinion of posting patches as attachments
> > has changed over the last few years.  Mailers have been getting
> > a lot better at handling them, even quoting non-message-body
> > plain/text attachments in replies.
> 
> There is also the problem of things like gmail/yahoo where you can't
> control the word wrapping.  The only way to submit patches from those
> services is as an plain text attachment. If you try to submit then
> in-line and they wrap wrong you will collect a lot of hate mail from
> Andrew.

Well, IMHO, if your mailer does not handle patches correctly, you can try to
include your patch in the message body and say something like "sorry, my
mailer messes up with patches so I'm attaching it too", _and_ attach it ...

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

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

[Dmitry Torokhov]

On 5/4/05, Dave Hansen <haveblue@us.ibm.com> wrote:
> 
> I think the general opinion of posting patches as attachments
> has changed over the last few years.  Mailers have been getting
> a lot better at handling them, even quoting non-message-body
> plain/text attachments in replies.

What, Linus updated his pine?????

-- 
Dmitry

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

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

On Wed, 04 May 2005 10:01:56 PDT, Dave Hansen said:

> -6) No MIME, no links, no compression, no attachments.  Just plain text.
> +6) No MIME, no links, no compression.  Just plain text.

Logically buggy.  You can't have an attachment without the MIME markup that
*says* it's an attachment.  I think what you meant was "No Content-Type-Encoding":
i.e. 'none' is acceptable, but 'quoted-printable' (which causes all the
spurious =20 and =3D you sometimes see) and 'base64' (uuencode on steroids)
aren't....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

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

[Dave Hansen]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

On Wed, 2005-05-04 at 13:16 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 04 May 2005 10:01:56 PDT, Dave Hansen said:
> 
> > -6) No MIME, no links, no compression, no attachments.  Just plain text.
> > +6) No MIME, no links, no compression.  Just plain text.
> 
> Logically buggy.  You can't have an attachment without the MIME markup that
> *says* it's an attachment.  I think what you meant was "No Content-Type-Encoding":
> i.e. 'none' is acceptable, but 'quoted-printable' (which causes all the
> spurious =20 and =3D you sometimes see) and 'base64' (uuencode on steroids)
> aren't....

Thanks for pointing out my flawed logic.  I wasn't quite sure what was
MIME and what wasn't.  How about the attached patch, instead?

-- Dave

[-- Attachment #2: submitting-patches-1.patch --]
[-- Type: text/x-patch, Size: 2728 bytes --]


I think the general opinion of posting patches as attachments
has changed over the last few years.  Mailers have been getting
a lot better at handling them, even quoting non-message-body
plain/text attachments in replies.  

Plus, a plain/text attachment message saved to a file can go
into 'patch' the same way that an inline one can.

Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
---

 memhotplug-dave/Documentation/SubmittingPatches |   20 ++++++++++++++------
 1 files changed, 14 insertions(+), 6 deletions(-)

diff -L Documentation/Submitting -puN /dev/null /dev/null
diff -puN Documentation/SubmittingPatches~submitting-patches Documentation/SubmittingPatches
--- memhotplug/Documentation/SubmittingPatches~submitting-patches	2005-05-04 08:07:25.000000000 -0700
+++ memhotplug-dave/Documentation/SubmittingPatches	2005-05-04 10:22:43.000000000 -0700
@@ -181,25 +181,33 @@ patches. Trivial patches must qualify fo
 
 
 
-6) No MIME, no links, no compression, no attachments.  Just plain text.
+6) No links, no compressed attachments.  Just plain text.
 
 Linus and other kernel developers need to be able to read and comment
 on the changes you are submitting.  It is important for a kernel
 developer to be able to "quote" your changes, using standard e-mail
 tools, so that they may comment on specific portions of your code.
 
-For this reason, all patches should be submitting e-mail "inline".
+For this reason, the preferred way of submitting patches in e-mail is
+"inline", in the same part of the message with everything else.
 WARNING:  Be wary of your editor's word-wrap corrupting your patch,
 if you choose to cut-n-paste your patch.
 
-Do not attach the patch as a MIME attachment, compressed or not.
+Many maintainers will now accept patches submitted to them as
+text/plain attachments.  Many mailers quote these attachements in the
+same way that they do for inline patches.  But, some maintainers still
+prefer inlines and they are certainly the safest bet.  In any case,
+never attach more than one patch to a single e-mail.
+
 Many popular e-mail applications will not always transmit a MIME
 attachment as plain text, making it impossible to comment on your
-code.  A MIME attachment also takes Linus a bit more time to process,
-decreasing the likelihood of your MIME-attached change being accepted.
+code.  If you must use an attachment, verify that it has no
+Content-Type-Encoding.  A MIME attachment also takes Linus a bit more
+time to process, decreasing the likelihood of your MIME-attached
+change being accepted.
 
 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.
 
 
 
_

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

[Chris Wright]

* Dave Hansen (haveblue@us.ibm.com) wrote:
> On Wed, 2005-05-04 at 13:16 -0400, Valdis.Kletnieks@vt.edu wrote:
> > On Wed, 04 May 2005 10:01:56 PDT, Dave Hansen said:
> > 
> > > -6) No MIME, no links, no compression, no attachments.  Just plain text.
> > > +6) No MIME, no links, no compression.  Just plain text.
> > 
> > Logically buggy.  You can't have an attachment without the MIME markup that
> > *says* it's an attachment.  I think what you meant was "No Content-Type-Encoding":
> > i.e. 'none' is acceptable, but 'quoted-printable' (which causes all the
> > spurious =20 and =3D you sometimes see) and 'base64' (uuencode on steroids)
> > aren't....
> 
> Thanks for pointing out my flawed logic.  I wasn't quite sure what was
> MIME and what wasn't.  How about the attached patch, instead?

I agree that things are better.  But, ironically, this patch is a case
in point.  It's attached as text/x-patch and makes replying to and
commenting on patch inline more laborious.  Perhaps it should be clear,
text/plain tends to work (and is better than inline whitespace damaged
patches).  Andrew's "The Perfect Patch" has some text you could lift.

http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt

thanks,
-chris

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

[Dave Hansen]

On Wed, 2005-05-04 at 10:55 -0700, Chris Wright wrote:
> I agree that things are better.  But, ironically, this patch is a case
> in point.  It's attached as text/x-patch and makes replying to and
> commenting on patch inline more laborious.

Well, crap.

I've sent an awful lot of patches that way, and never had a negative
reply from a maintainer or a patch commenter.

As an aside: is there a proper way to do patch text/plain attachments
from Evolution?  Maybe we need a quick tutorial on what the best way to
send patches is with several popular mailers.

-- Dave

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

[Alexander Nyberg]

ons 2005-05-04 klockan 11:14 -0700 skrev Dave Hansen:
> On Wed, 2005-05-04 at 10:55 -0700, Chris Wright wrote:
> > I agree that things are better.  But, ironically, this patch is a case
> > in point.  It's attached as text/x-patch and makes replying to and
> > commenting on patch inline more laborious.
> 
> Well, crap.
> 
> I've sent an awful lot of patches that way, and never had a negative
> reply from a maintainer or a patch commenter.
> 
> As an aside: is there a proper way to do patch text/plain attachments
> from Evolution?  Maybe we need a quick tutorial on what the best way to
> send patches is with several popular mailers.
> 

In evolution I just do new mail => insert => text file and change the
mail to preformat instead of normal formatting. I'm sure there are
settings somewhere to make this default but I don't send enough patches
(yet) to bother, the output works anyway (old patch shown below):

Index: linux-2.6/arch/x86_64/kernel/head64.c
===================================================================
--- linux-2.6.orig/arch/x86_64/kernel/head64.c	2005-04-26 11:41:43.000000000 +0200
+++ linux-2.6/arch/x86_64/kernel/head64.c	2005-04-29 11:57:46.000000000 +0200
@@ -93,9 +93,6 @@
 #ifdef CONFIG_SMP
 	cpu_set(0, cpu_online_map);
 #endif
-	/* default console: */
-	if (!strstr(saved_command_line, "console="))
-		strcat(saved_command_line, " console=tty0"); 
 	s = strstr(saved_command_line, "earlyprintk=");
 	if (s != NULL)
 		setup_early_printk(s);

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

[Jeff Garzik]

Dave Hansen wrote:
> As an aside: is there a proper way to do patch text/plain attachments
> from Evolution?  Maybe we need a quick tutorial on what the best way to
> send patches is with several popular mailers.

I feel this is needed, yes.  Don't forget to include Microsoft Outlook :)

	Jeff

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

[Dipankar Sarma]

On Wed, May 04, 2005 at 10:25:16AM -0700, Dave Hansen wrote:
> On Wed, 2005-05-04 at 13:16 -0400, Valdis.Kletnieks@vt.edu wrote:
> > On Wed, 04 May 2005 10:01:56 PDT, Dave Hansen said:
> > 
> > > -6) No MIME, no links, no compression, no attachments.  Just plain text.
> > > +6) No MIME, no links, no compression.  Just plain text.
> > 
> > Logically buggy.  You can't have an attachment without the MIME markup that
> > *says* it's an attachment.  I think what you meant was "No Content-Type-Encoding":
> > i.e. 'none' is acceptable, but 'quoted-printable' (which causes all the
> > spurious =20 and =3D you sometimes see) and 'base64' (uuencode on steroids)
> > aren't....
> 
> Thanks for pointing out my flawed logic.  I wasn't quite sure what was
> MIME and what wasn't.  How about the attached patch, instead?

I don't like it, but that is only because your mailer sends
them as test/x-patch and my mailer cannot quote the patch in reply :)

Thanks
Dipankar

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

[Krzysztof Halasa]

Dave Hansen <haveblue@us.ibm.com> writes:

> +Many maintainers will now accept patches submitted to them as
> +text/plain attachments.  Many mailers quote these attachements in the
> +same way that they do for inline patches.  But, some maintainers still
> +prefer inlines and they are certainly the safest bet.

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:

From: xxx@yyy
To: lkml
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
--=-=-=

Normal message text etc.

--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline; filename=xxx.patch

--- linux-2.6/xxx.c 25 May 2003 22:13:37
+++ linux-2.6/xxx.c 25 May 2003 22:13:38
the rest of patch text

--=-=-=--

> +code.  If you must use an attachment,

Nearly no one "must" use attachments. I can only think of people using
broken mail servers ("corporate servers").

> 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.
-- 
Krzysztof Halasa

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

[Randy.Dunlap]

[-- Attachment #1: Type: text/plain, Size: 2446 bytes --]

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 #2: check-patch.pl --]
[-- Type: application/octet-stream, Size: 2950 bytes --]

#! /usr/bin/perl
# Randy Dunlap <rddunlap@osdl.org>
# 2005-05-02
#
#Matt Mackall wrote:
#I think a mail robot that you could send patches to that would detect:
#- quoted printable
#- line wrapping
#- tab damage
#- wrong directory level
#- non-unidiff
#- added trailing whitespace
#- etc.
#- lines longer than 80 characters
#- use of // style comments
#
#..would be quite useful. Then we could just say "your patch is
#damaged, resend to patch-tester@foo.org until it says it looks ok".
#
#Any volunteers? 
#-- 

$tabcount = 0;
$spaces_run = 0;
$trailing_ws = 0;
$double_slashes = 0;
$bad_encodings = 0;
$not_unidiff = 0;
$not_pdiff = 0;
$bad_subdir = 0;

%kernel_dirs = ("arch", 1, "crypto", 1, "drivers", 1, "fs", 1,
		"include", 1, "init", 1, "ipc", 1, "kernel", 1,
		"lib", 1, "mm", 1, "net", 1, "scripts", 1,
		"security", 1, "sound", 1, "usr", 1, "Documentation", 1);

# get input file name:
$INPUTNAME = $ARGV[0];

if (length ($INPUTNAME) == 0) {
        print "usage: check-patch.pl patchfile\n\n";
        exit 1;
}

if (! open (INPUTNUM, "<$INPUTNAME")) {
        print "cannot open '$INPUTNAME'\n\n";
        exit 2;
}

print "$INPUTNAME :\n";

readpatch: while ($line = <INPUTNUM>)
{
	chomp $line;
	# print "deb: #line = {$line}\n";

	$tabcount++ if $line =~ /\t/;
	$spaces_run++ if $line =~ /    /;
	$trailing_ws++ if $line =~ /^\+.*[ \t]$/;
	$double_slashes++ if $line =~ /\/\//;

	if ($line =~ /Content-Transfer-Encoding:/i) {
		if (($line =~ /base64/i) ||
		    ($line =~ /binary/i) ||
		    ($line =~ /quoted-printable/i)) {
			$bad_encodings++;
			print "bad encoding: $line\n";
		}
	}

	if ($line =~ /^diff/) {
		if ($line !~ /-.*u/) {
			print "appears not to be a -u diff\n";
			$not_unidiff++;
		}
		if ($line !~ /-.*p/) {
			print "appears not to be a -p diff\n";
			$not_pdiff++;
		}
	}

	if ($line =~ /^--- / || $line =~ /^\+\+\+ /) {
		$filename = substr($line, 4);
		@diffline = split(' ', $filename); # filename date time
		@fnparts = split('/', $diffline[0]);
		$subdir = $fnparts[1];
		if ((substr($subdir, length($subdir) - 1, 1) eq '/') &&
		       ($kernel_dirs{$subdir} != 1)) {
			$ending = substr($subdir, length($subdir) - 1, 1);
			print "bad sub-dir level {$ending}[$subdir]: $line\n";
			$bad_subdir++;
		}
	}
} # end readpatch

close (INPUTNUM);

print "  tab count: $tabcount\n";
print "  spaces_run count: $spaces_run\n";

print "  trailing whitespace: $trailing_ws\n";
print "  bad encodings: $bad_encodings\n";
print "  '//' comments: $double_slashes\n";
print "  not -u diff: $not_unidiff\n";
print "  not -p diff: $not_pdiff\n";
print "  bad sub-dir level: $bad_subdir\n";

if ($tabcount == 0 && $spaces_run > 0) {
	print "  WARNING: no tabs found, lots of spaces found; not a good sign\n";
}

$errs = $trailing_ws + $bad_encodings + $double_slashes + $not_unidiff + $not_pdiff
	+ $bad_subdir;

if ($errs == 0) {
	print "  PASS (no errors)\n";
}
else {
	print "  ##### $errs error(s) #####\n";
}

# end.

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

[Domen Puncer]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

On 04/05/05 12:28 -0700, Randy.Dunlap wrote:
> 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.

I made a simpler (it's only regexes :-) ) and uglier version, which
does check for line wrapping.
I probably won't have too much time to work on it, so feel free
to do whatever you want with it.

> 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.

I put mine on patch-tester@coderock.org ... don't abuse it too
much, it's just an old pentium on adsl there :-)


	Domen

[-- Attachment #2: patch-tester.pl --]
[-- Type: application/x-perl, Size: 2922 bytes --]

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

[John W. Linville]

On Wed, May 04, 2005 at 10:01:56AM -0700, Dave Hansen wrote:
> 
> I think the general opinion of posting patches as attachments
> has changed over the last few years.  Mailers have been getting
> a lot better at handling them, even quoting non-message-body
> plain/text attachments in replies.  

Personally, I hate seeing patches as attachments.  No offense, but
I hope this patch is ignored.

John
-- 
John W. Linville
linville@tuxdriver.com

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

[Rik van Riel]

On Wed, 4 May 2005, Dave Hansen wrote:

> Plus, a plain/text attachment message saved to a file can go
> into 'patch' the same way that an inline one can.

The problem is replying to an attachment.  The reason why having
the patch in the main mail body is good is that it gets quoted
by the email software and you can easily reply to individual
parts of the patch.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

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

[Geert Uytterhoeven]

On Wed, 4 May 2005, Rik van Riel wrote:
> On Wed, 4 May 2005, Dave Hansen wrote:
> > Plus, a plain/text attachment message saved to a file can go
> > into 'patch' the same way that an inline one can.
> 
> The problem is replying to an attachment.  The reason why having
> the patch in the main mail body is good is that it gets quoted
> by the email software and you can easily reply to individual
> parts of the patch.

Indeed. `perfect' patches as attachments are fine. Maybe that's why some people
testified they never got complaints about their attached patches :-)

But as soon as you have to point out some comments, replying takes a lot more
time (save attachment, load it in editor, prepend every line with `> ', ...),
and may lead to maintainer burn-out.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

[Krzysztof Halasa]

Rik van Riel <riel@redhat.com> writes:

> The problem is replying to an attachment.  The reason why having
> the patch in the main mail body is good is that it gets quoted
> by the email software and you can easily reply to individual
> parts of the patch.

If the attachment is "disposition=inline", does the problem still exist?
-- 
Krzysztof Halasa

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

[Paulo Marques]

Krzysztof Halasa wrote:
> Rik van Riel <riel@redhat.com> writes:
> 
> 
>>The problem is replying to an attachment.  The reason why having
>>the patch in the main mail body is good is that it gets quoted
>>by the email software and you can easily reply to individual
>>parts of the patch.
> 
> 
> If the attachment is "disposition=inline", does the problem still exist?

I've just checked this with Thunderbird (which is the mail client I use).

It not only sets the disposition=inline by default when attaching 
patches, it also places the patch inline when replying to it, allowing 
the user to write between the text of the patch as if it were part of 
the email text.

However if we Copy+Paste the patch into the mail it gets line wrapped / 
white space mangled.

So at least for Thunderbird users it would be better to use attached 
patches with "Content-Disposition: inline".

-- 
Paulo Marques - www.grupopie.com

All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)

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

[Steven Cole]

Paulo Marques wrote:
> Krzysztof Halasa wrote:
> 
>> Rik van Riel <riel@redhat.com> writes:
>>
>>
>>> The problem is replying to an attachment.  The reason why having
>>> the patch in the main mail body is good is that it gets quoted
>>> by the email software and you can easily reply to individual
>>> parts of the patch.
>>
>>
>>
>> If the attachment is "disposition=inline", does the problem still exist?
> 
> 
> I've just checked this with Thunderbird (which is the mail client I use).
> 
> It not only sets the disposition=inline by default when attaching 
> patches, it also places the patch inline when replying to it, allowing 
> the user to write between the text of the patch as if it were part of 
> the email text.
> 
> However if we Copy+Paste the patch into the mail it gets line wrapped / 
> white space mangled.

That depends on where you are Copy+Pasting from.  Granted, Copy+Paste from
a variety of sources is a nightmare.  But, Copy+Paste from Tbird to Tbird
seems to actually work.

> 
> So at least for Thunderbird users it would be better to use attached 
> patches with "Content-Disposition: inline".
> 

Here is a trick you can play with Thunderbird to get inlined patches:

1) Mail the patch to yourself as an attachment.
2) Read the mail you just got, copy and paste the patch to your new message.

This method preserves the tabs/whitespace. Of course, you have to set the
wordwrap settings appropriately. It works for me.

Steven

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

[Lee Revell]

On Thu, 2005-05-05 at 15:34 -0600, Steven Cole wrote:
> Paulo Marques wrote:
> > 
> > However if we Copy+Paste the patch into the mail it gets line wrapped / 
> > white space mangled.
> 
> That depends on where you are Copy+Pasting from.  Granted, Copy+Paste from
> a variety of sources is a nightmare.  But, Copy+Paste from Tbird to Tbird
> seems to actually work.
> 
> > 
> > So at least for Thunderbird users it would be better to use attached 
> > patches with "Content-Disposition: inline".
> > 
> 
> Here is a trick you can play with Thunderbird to get inlined patches:
> 
> 1) Mail the patch to yourself as an attachment.
> 2) Read the mail you just got, copy and paste the patch to your new message.
> 
> This method preserves the tabs/whitespace. Of course, you have to set the
> wordwrap settings appropriately. It works for me.

Personally, I don't understand people who can hack the kernel but
complain about bugs in their mail client.

Lee

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

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

On Thu, 05 May 2005 21:31:30 EDT, Lee Revell said:
> Personally, I don't understand people who can hack the kernel but
> complain about bugs in their mail client.

In some cases, the kernel is less lines of better-understood code.. :)

Current Fedora-devel tree:
-rw-rw-r--    1 33474781   Mar 31 00:09   thunderbird-1.0.2-1.src.rpm
-rw-r--r--    1 42109198   May  4 18:52   kernel-2.6.11-1.1286_FC4.src.rpm

(And the kernel doesn't drag in Xorg and Gnome libraries on top of that like
thunderbird does)....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

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

[Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>]

Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On 5/4/05, Dave Hansen <haveblue@us.ibm.com> wrote:

>> I think the general opinion of posting patches as attachments
>> has changed over the last few years.  Mailers have been getting
>> a lot better at handling them, even quoting non-message-body
>> plain/text attachments in replies.
> 
> What, Linus updated his pine?????

Pine is usurally better for handling patches than other mailers.
In pine, you can save a message into a mbox using very few keystrokes,
and if the patches are not encoded, patch can parse them from there.



BTW: I wrote a tool for handling MIME mails. Originally it was intended to
catch spam in procmail, but it can safe the individual parts into seperate
files, too. Maybe this is usefull:

http://7eggert.dyndns.org/~7eggert/hp/l/spam+mail/mime-analyzer/

(You'd use "cd $destdir && formail < $mbox -s mail-analyzer -copy_all -")
-- 
According to my calculations the problem doesn't exist.