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 <[email protected]>
---
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
_
On 5/4/05, Dave Hansen <[email protected]> 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
[email protected]
On 5/4/05, Dave Hansen <[email protected]> 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
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....
On Wed, 2005-05-04 at 13:16 -0400, [email protected] 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
On Wed, 2005-05-04 13:10:35 -0400, Jon Smirl <[email protected]> wrote:
> On 5/4/05, Dave Hansen <[email protected]> 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 [email protected] . +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));
* Dave Hansen ([email protected]) wrote:
> On Wed, 2005-05-04 at 13:16 -0400, [email protected] 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
On Wed, May 04, 2005 at 10:25:16AM -0700, Dave Hansen wrote:
> On Wed, 2005-05-04 at 13:16 -0400, [email protected] 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
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
[email protected]
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
On Wed, 4 May 2005, Jan-Benedict Glaw wrote:
> On Wed, 2005-05-04 13:10:35 -0400, Jon Smirl <[email protected]> wrote:
>> On 5/4/05, Dave Hansen <[email protected]> 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.
Dave Hansen <[email protected]> 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
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);
On Wed, 04 May 2005 20:52:45 +0200
Krzysztof Halasa <[email protected]> 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
Hi,
On Wednesday, 4 of May 2005 19:10, Jon Smirl wrote:
> On 5/4/05, Dave Hansen <[email protected]> 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"
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
Dmitry Torokhov <[email protected]> wrote:
> On 5/4/05, Dave Hansen <[email protected]> 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.
On Wed, 2005-05-04 14:23:36 -0400, Richard B. Johnson <[email protected]> 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 [email protected] . +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));
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 -- [email protected]
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
Rik van Riel <[email protected]> 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
Krzysztof Halasa wrote:
> Rik van Riel <[email protected]> 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 - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
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 <[email protected]> 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
On Thu, 2005-05-05 12:43:39 -0400, Lee Revell <[email protected]> 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 [email protected] . +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));
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
Paulo Marques wrote:
> Krzysztof Halasa wrote:
>
>> Rik van Riel <[email protected]> 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
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
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)....
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 [email protected] ... don't abuse it too
much, it's just an old pentium on adsl there :-)
Domen