Hello, this patch adds a new paragraph describing some configuration tweaks required for some e-mail clients to send good patches. I only know about Mozilla Mail and KMail, but I hope other developers will follow up with similar tips for other popular clients. Passes as valid XHTML 1.0 Transitional with the W3C validator. Index: contribute.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/contribute.html,v retrieving revision 1.57 diff -u -p -r1.57 contribute.html --- contribute.html 12 Jan 2004 22:03:21 -0000 1.57 +++ contribute.html 25 Jun 2004 19:24:04 -0000 @@ -24,6 +24,7 @@ contributions must meet:

  • Documentation Changes
  • Web Site Changes
  • Submitting Patches
    • +
  • Tweaking E-Mail Clients
    • @@ -108,7 +109,7 @@ If you already did a complete C,C++,Java directory before, you can use the following:

     make clean-target-libstdc++-v3                    # clean libstdc++ and ...
-test -d */libjava && make -C */libjava clean-nat  # ... parts of libjava
+test -d */libjava && make -C */libjava clean-nat  # ... parts of libjava
 make all-target-libstdc++-v3 all-target-libjava   # rebuild compiler and libraries
 make -k check-c++                                 # run C++/libstdc++ testsuite
    @@ -241,17 +242,10 @@ changes easier but do not change GCC's b the changes that actually make use of the new code and change GCC's behavior.)

    -

    We prefer patches posted as plain text or as MIME parts of type -text/x-patch or text/plain, disposition -inline, encoded as 7bit or -8bit. -It is strongly discouraged to post patches as MIME parts of type -application/whatever, disposition -attachment or encoded as base64 or -quoted-printable. Avoid MIME large-message splitting -(message/partial) at all costs.

    +

    Before sending the patch, make sure your e-mail client is +correctly configured. -

    If the patch is too big or too mechanical, posting it gzipped or +

    If the patch is too big or too mechanical, posting it gzipped or bzip2ed and uuencoded or encoded as a base64 MIME part is acceptable, as long as the ChangeLog is still posted as plain text.

    @@ -277,5 +271,57 @@ no-one else will need to apply it to the totally new files may be omitted (especially if large) since they can be accessed directly from the repository.

    + +

    Tweaking E-Mail Clients

    + +

    We prefer patches posted as plain text or as MIME parts of type +text/x-patch or text/plain, disposition +inline, encoded as 7bit or +8bit. +It is strongly discouraged to post patches as MIME parts of type +application/whatever, disposition +attachment or encoded as base64 or +quoted-printable. Avoid MIME large-message splitting +(message/partial) at all costs.

    + +

    The default configuration of many e-mail clients is inappropriate for +patch submissions. These are the correct settings to use with some +popular clients:

    + +
    + +
    Mozilla Mail
    +
    +

    In "Edit / Mail & Newsgroups Account Settings / YOUR-ACCOUNT / +Composition & Addressing", uncheck "Compose messages +in HTML format".

    + +

    In "Edit / Preferences / Mail & Newsgroups / +Composition", write "0" in the +"Wrap text messages at N characters" edit box.

    + +

    Disable RFC 2646 flowed-format by setting the following options in +"about:config" or in the "prefs.js" +configuration file:

    +
    +  mailnews.display.disable_format_flowed_support = true
+  mailnews.send_plaintext_flowed = false
+
    + +
    + +
    KMail
    +
    +

    In "Settings/Configure KMail/Composer/General", +uncheck the "Word wrap at column N" option.

    + +

    Be aware that KMail incorrectly strips form-feed characters +(^L) in sent mail. Even when word-wrap is disabled, KMail wraps +long lines when forwarding messages as inline, thus corrupting patches. +There are no known work-arounds for both these problems.

    +
    + +
    +