- Project tools
-
-
- Announcements
- Additional Resources
-
- How do I...
-
| Category |
Featured projects |
| scm |
Subversion,
Subclipse,
TortoiseSVN,
RapidSVN
|
| issuetrack |
Scarab |
| requirements |
xmlbasedsrs |
| design |
ArgoUML |
| techcomm |
SubEtha,
eyebrowse,
midgard,
cowiki |
| construction |
antelope,
scons,
frameworx,
build-interceptor,
propel,
phing
|
| testing |
maxq,
aut
|
| deployment |
current |
| process |
ReadySET |
| libraries |
GEF,
Axion,
Style,
SSTree
|
| Over 500 more tools... |
|
Welcome to the new Tigris! There have been some changes to the administration of mail lists. Project and list owners should check out the Discussion Services release notes.
Subversion Mailing Lists
If you have a question, please post it to:
You do not need to be subscribed to post. But if it's
your first post, there may be a small delay (one day or so) before
your mail appears, because the moderators have to approve the
unrecognized address. After the first time, there should be no more
delay.
Subscribing:
To subscribe to the users@ mailing list, email users-subscribe@subversion.tigris.org from the address you want
subscribed. Or, if you have already registered a
tigris.org account, you can subscribe by clicking the appropriate
button on this Web page.
Searching the Archives:
It's often useful to search the mailing list archives before
posting or replying: someone may have already reported the bug you're
about to report, for example, or have already written the answer
you're about to write. If the search functions at one of these
archives don't do what you need, try one of the
alternates — they're all copies of the same data, but
they offer different interfaces:
In addition to searching the mailing list archives, you should also
try the other help resources
available.
Announcements
If you only want to receive mail about important announcements,
just subscribe to announce@subversion.tigris.org.
See the appropriate section of this page for more
details.
Reporting Bugs
Please report bugs on the users@subversion.tigris.org list first, to get confirmation that
what you found actually is a bug. Once it's confirmed, then
you can post to dev@ with a full report. You should allocate some
time for this: writing a useful bug report generally takes at least
fifteen minutes, and sometimes a half-hour or even more if the
reproduction recipe is complicated. See the bug
report guidelines for instructions on how to write a good bug
report.
WE REALLY MEAN THAT :-). We get too many
useless bug reports, just saying "It didn't work" without providing
any details (such as what version of Subversion was being used on both
the client and server sides, what behavior the user expected,
transcripts of the exact command and the exact output, etc). If you
haven't read the bug report guidelines, please
read them now. Here's that link again: bug report
guidelines.
Mailing List Etiquette
The advice below is based on years of experience with the
Subversion mailing lists, and addresses the problems seen most
frequently on those lists. It should not be taken as a
complete guide to mailing list etiquette — you can find one of those on the Net pretty easily if you want one.
If you follow these conventions when posting to
users@subversion.tigris.org or dev@subversion.tigris.org, your post is
much more likely to be read and answered.
Where to post:
When in doubt, mail users@subversion.tigris.org, not dev@subversion.tigris.org.
There are many experienced people (including some of Subversion's
maintainers) on users@ list — they may be able to
answer your question, or if you think you've found a bug they can
determine whether or not it is a genuine bug. You should even post to
users@ when you want to suggest a new feature: many feature
suggestions are ideas that have been discussed before, and someone on
the users@subversion.tigris.org mailing list will usually be able to
tell if that's the case with your suggestion.
Please do not post to dev@ as a last resort after failing to
get an answer on users@. The two lists have different charters:
users@ is a support forum, dev@ is a development discussion list.
When a support question goes unanswered on users@, that is
unfortunate, but it does not make the question appropriate for dev@.
Of course, if the mail is about a possible bug in Subversion, and
got no reaction on users@, then asking on dev@ is
fine — bugs are a development topic. And patches should always be sent
directly to dev@.
When to post
Sometimes, when really impassioned about a topic, it's tempting to
respond to every message in a mail thread. Please don't do this. Our
mailing lists are already high-traffic, and following up to every
message only adds to the noise.
Instead, read the entire mail thread, think carefully about what
you have to say, pick a single message to reply to, and then lay out
your thoughts. Occasionally it might make sense to reply to two
separate messages in a thread, but only if the topics have started to
diverge.
Reply-To
Make sure to use your mailreader's "Follow-up" or "Reply-to-all" or
"Group reply" feature when responding to a list post. Otherwise, your
mail will only go to the author of the original post, not to the whole
list. Unless there's a reason to reply privately, it's always better
to respond to the list, so everyone can watch and learn. (Also, many
people who frequently get private responses to their posts have
indicated that they would prefer those responses to go to the list
instead.)
Note that the Subversion mailing lists do not modify the
Reply-to header to redirect responses to the list. They
leave Reply-to set to whatever the original sender had, for
the reasons listed in http://www.unicom.com/pw/reply-to-harmful.html, in particular the
"Principle of Least Damage" and "Can't Find My Way Back Home"
sections. From time to time, someone posts asking why we don't set
the Reply-to header. Sometimes that person will mention http://www.metasystema.net/essays/reply-to.mhtml, which
gives arguments in favor of modifying the Reply-to field.
The list administrators are aware of both documents, and see that both
sides of the argument have merits, but in the end have chosen not to
modify the Reply-to headers. Please don't resurrect the
topic.
Making a Fresh Post
Don't start a new thread (subject) by replying to an existing
post. Instead, start a fresh mail, even if that means you have to
write out the list address by
hand. If you reply to an existing post, your mailreader may include
metadata that marks your post as a followup in that thread. Changing
the Subject header is not enough to prevent this! Many
mailreaders will still preserve enough metadata to put your post in
the wrong thread. If this happens, not only will some people not see
your post (because they're ignoring that thread), but people who are
reading the thread will waste their time with your off-topic post.
The safest way to avoid this is to never use "reply" to start a new
topic.
(The root of the problem is really that some mail interfaces do
not indicate that the message generated by the "Reply" function is
different from a fresh message. If you use such a program, consider
submitting an enhancement request or a patch to its developers to make
it show a distinction.)
Re-threading
If you do need to change the Subject header while
preserving the thread (perhaps because the thread has wandered into
some other topic), do it by making a post under the new subject with
the old subject in parenthesis, like this:
Blue asparagus
|
|_ Re: Blue asparagus
|
|_ Yellow elephants (was: Re: Blue asparagus) <-- ### switch ###
|
|_ Re: Yellow elephants
Top-Posting
Please don't reflexively chide people for top-posting.
"Top-posting" is the practice of putting the response text above the
quoted text, instead of interleaved with it or below it. Usually, the
quoted text provides essential context for understanding the response,
and so top-posting is a hindrance. Sometimes, people top-post when it
would have been better to inter-post or bottom-post, and others chide
them for this. If you must chide, do it gently, and certainly don't
bother to make an extra post just to point out a minor problem like
this. There are even situations where top-posting is
preferable — for example, when the response is short
and general, and applies to the entirety of a long passage of quoted
text. So top-posting is always a judgement call, and in any case it's
not a major inconvenience even when done inappropriately.
If you came here looking for advice on how to quote, instead of
advice on how to not flame people for their bad quoting habits, see http://www.netmeister.org/news/learn2quote.html (Deutsch:
http://learn.to/quote).
Languages and encodings:
Please use ASCII or ISO-8859 text if possible. Don't post HTML
mails, RichText mails, or other formats that might be opaque to
text-only mailreaders. Regarding language: we don't have an
English-only policy, but you will probably get the best results by
posting in English — it is the language shared by the
greatest number of list participants.
|