You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Reser <be...@reser.org> on 2004/09/10 04:39:13 UTC
Re: svn commit: r10809 - trunk/www
On Fri, Sep 03, 2004 at 12:01:11AM -0500, kfogel@tigris.org wrote:
> Author: kfogel
> Date: Fri Sep 3 00:01:08 2004
> New Revision: 10809
>
> Added:
> trunk/www/mailing-list-guidelines.html
> Modified:
> trunk/www/project_tools.html
> Log:
> * www/mailing-list-guidelines.html: New file. Thanks to Paul
> Puschmann <pa...@medcom-service.de> for suggesting
> this and providing some initial material.
Couple comments on this set of guidelines...
There should be a section specifying that we don't consider consider it
appropriate to use derogatory or inflamatory language.
> +<a name="line-length"></a>
> +<li>
> +<p>Try not to use lines longer than 72 columns. This only applies to
> +the prose part of your message, of course. If you're <a
> +href="#patches">including a patch</a> or other specially formatted
> +text, those lines should be left at their original lengths. Watch
> +out: some mailers do a kind of automatic line-wrapping, whereby when
> +you're writing your mail the display shows line breaks that aren't
> +actually there. There's usually a setting you can tweak to make it
> +stop doing that.<p>
> +</li>
Probably should just mention to see the section on patches for line
length issues regarding them, rather than duplicating them.
It might be useful to explain "Why 72 columns?"
Many people are using 80 column terminals to read their email. Using 72
columns leaves room for quoting characters to be added for future
replies without needing to rewrap the text to avoid it looking
exceedingly ugly.
> +<h2>Sending patches:</h2>
> +<a name="patches"></a>
> +
> +<ul>
> +
> +<li>
> +<p>If you're posting a patch, start the subject line with
> +<tt>[PATCH]</tt>. This helps our patch manager spot patches right
> +away. If the patch addresses a particular issue, include the issue
> +number as well: "<tt>[PATCH] issue #1729: ...</tt>".
> +Developers who are interested in that particular issue will know to
> +read the mail.</p>
> +
> +<p>It is unfortunately common for some mailreaders to munge patch text
> +that is included inline in the message body, for example by inserting
> +line breaks in the middle of long lines. If you think your mailreader
> +might do this, then send the patch as an attachment instead of putting
> +it directly in the message body. But if your mailreader doesn't
> +munge message bodies, then put the patch inline, because it's a bit
> +easier for people to see that way.</p>
> +</li>
I don't think everyone universally agrees with this. I much prefer
attachments provided that they have reasonable mime types specified.
text/x-diff, text/x-patch and text/plain are shown to me inline by my
mail client. Using an attachment saves me the bother of having to save
the entire message and edit it to get a clean patch if I want to apply
it later.
So I would revise this to specify that you should attach your patches if
you can do so with one of the above MIME types, if not you can inline it
provided your mail client won't munge it. As a last resort a patch can
be attached with some other mime type. Also patches should never be
archived or compressed (e.g. tar, gzip, zip, bzip2).
In my experience nobody seems to mind attachments provided they have
these reasonable mime types and aren't archived or compressed.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10809 - trunk/www
Posted by Max Bowsher <ma...@ukf.net>.
Justin Erenkrantz wrote:
> --On Friday, September 10, 2004 12:51 PM -0500 kfogel@collab.net wrote:
>
>> My reasons for preferring patches to be included inline (by which I
>> mean, directly in the body of the message, instead of as attachments
>> that get displayed inline) are unimaginably subtle and certainly not
>> to be imposed on the sane, sensible people who share this mailing list
>> with the likes of me. Trust me, you don't want to know.
>
> AIUI, Outlook can't attach patches correctly no matter what you try. The
> failure case of an attached patch with the wrong MIME type is really,
> really
> annyoing. -- justin
Does adding a .txt extension to the file help?
I use OE (it sucks, but in ways I'm acclimated to), and by making a registry
tweak, I've persuaded it to assign a good MIME type to .patch files:
Root-key HKCR
Key ".patch"
String-value "Content Type" = "text/plain"
Works fine for me.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10809 - trunk/www
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, September 10, 2004 12:51 PM -0500 kfogel@collab.net wrote:
> My reasons for preferring patches to be included inline (by which I
> mean, directly in the body of the message, instead of as attachments
> that get displayed inline) are unimaginably subtle and certainly not
> to be imposed on the sane, sensible people who share this mailing list
> with the likes of me. Trust me, you don't want to know.
AIUI, Outlook can't attach patches correctly no matter what you try. The
failure case of an attached patch with the wrong MIME type is really, really
annyoing. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10809 - trunk/www
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
On Fri 2004-09-10 at 12:51:26 -0500, kfogel@collab.net wrote:
> Benjamin Pflugmann <be...@pflugmann.de> writes:
> > > Okay. I kind of prefer them inline, but I think I'm in a minority
> > > there; I'll change it to your suggestion above.
[...]
> I use GNUS, which does indeed display them (practically the same) as
> inline. I never said it didn't :-).
Apparently I misunderstood. Sorry about the noise.
Bye,
Benjamin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10809 - trunk/www
Posted by kf...@collab.net.
Benjamin Pflugmann <be...@pflugmann.de> writes:
> > Okay. I kind of prefer them inline, but I think I'm in a minority
> > there; I'll change it to your suggestion above.
>
> Sounds as if you didn't notice: As he said, his mail client is
> configured to display such mails (practically the same) as inline. I
> assume that would fulfill your needs, too, and this way, everyone can
> use the procedures (s)he likes most.
(Didn't notice what?)
> GNUS being versatile as it is, it should be possible with it, too. For
> mutt, I have to set the auto_view variable for these mime-types and have
> some lines in my ~/.mailcap:
>
> text/x-patch; cat; copiousoutput
> text/x-diff; cat; copiousoutput
>
> Hope that helps somehow.
I use GNUS, which does indeed display them (practically the same) as
inline. I never said it didn't :-).
My reasons for preferring patches to be included inline (by which I
mean, directly in the body of the message, instead of as attachments
that get displayed inline) are unimaginably subtle and certainly not
to be imposed on the sane, sensible people who share this mailing list
with the likes of me. Trust me, you don't want to know.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10809 - trunk/www
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
Hi.
On Fri 2004-09-10 at 12:03:49 -0500, you wrote
[...]
> > text/x-diff, text/x-patch and text/plain are shown to me inline by my
> > mail client.
[...]
> Okay. I kind of prefer them inline, but I think I'm in a minority
> there; I'll change it to your suggestion above.
Sounds as if you didn't notice: As he said, his mail client is
configured to display such mails (practically the same) as inline. I
assume that would fulfill your needs, too, and this way, everyone can
use the procedures (s)he likes most.
GNUS being versatile as it is, it should be possible with it, too. For
mutt, I have to set the auto_view variable for these mime-types and have
some lines in my ~/.mailcap:
text/x-patch; cat; copiousoutput
text/x-diff; cat; copiousoutput
Hope that helps somehow.
Bye,
Benjamin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10809 - trunk/www
Posted by kf...@collab.net.
Ben Reser <be...@reser.org> writes:
> Couple comments on this set of guidelines...
>
> There should be a section specifying that we don't consider consider it
> appropriate to use derogatory or inflamatory language.
I'm trying to keep it to stuff we actually see happening regularly.
We don't have much of a problem with derogatory or inflammatory
language on this list. In the rare cases where we do, my impression
is that it comes from people who are unlikely to change their behavior
just because we point them to a set of guidelines. (We usually react
quickly to quash it on the list anyway.)
> > +<a name="line-length"></a>
> > +<li>
> > +<p>Try not to use lines longer than 72 columns. This only applies to
> > +the prose part of your message, of course. If you're <a
> > +href="#patches">including a patch</a> or other specially formatted
> > +text, those lines should be left at their original lengths. Watch
> > +out: some mailers do a kind of automatic line-wrapping, whereby when
> > +you're writing your mail the display shows line breaks that aren't
> > +actually there. There's usually a setting you can tweak to make it
> > +stop doing that.<p>
> > +</li>
>
> Probably should just mention to see the section on patches for line
> length issues regarding them, rather than duplicating them.
>
> It might be useful to explain "Why 72 columns?"
>
> Many people are using 80 column terminals to read their email. Using 72
> columns leaves room for quoting characters to be added for future
> replies without needing to rewrap the text to avoid it looking
> exceedingly ugly.
Good suggestions both -- will tweak accordingly.
> > +<h2>Sending patches:</h2>
> > +<a name="patches"></a>
> > +
> > +<ul>
> > +
> > +<li>
> > +<p>If you're posting a patch, start the subject line with
> > +<tt>[PATCH]</tt>. This helps our patch manager spot patches right
> > +away. If the patch addresses a particular issue, include the issue
> > +number as well: "<tt>[PATCH] issue #1729: ...</tt>".
> > +Developers who are interested in that particular issue will know to
> > +read the mail.</p>
> > +
> > +<p>It is unfortunately common for some mailreaders to munge patch text
> > +that is included inline in the message body, for example by inserting
> > +line breaks in the middle of long lines. If you think your mailreader
> > +might do this, then send the patch as an attachment instead of putting
> > +it directly in the message body. But if your mailreader doesn't
> > +munge message bodies, then put the patch inline, because it's a bit
> > +easier for people to see that way.</p>
> > +</li>
>
> I don't think everyone universally agrees with this. I much prefer
> attachments provided that they have reasonable mime types specified.
> text/x-diff, text/x-patch and text/plain are shown to me inline by my
> mail client. Using an attachment saves me the bother of having to save
> the entire message and edit it to get a clean patch if I want to apply
> it later.
>
> So I would revise this to specify that you should attach your patches if
> you can do so with one of the above MIME types, if not you can inline it
> provided your mail client won't munge it. As a last resort a patch can
> be attached with some other mime type. Also patches should never be
> archived or compressed (e.g. tar, gzip, zip, bzip2).
>
> In my experience nobody seems to mind attachments provided they have
> these reasonable mime types and aren't archived or compressed.
Okay. I kind of prefer them inline, but I think I'm in a minority
there; I'll change it to your suggestion above.
Thanks for the feedback!
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org