procyberian/emacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

* etc/MAILINGLISTS: Remove the more extremely obsolete parts

Browse source
This commit is contained in:
Glenn Morris 2014-01-09 22:08:13 -05:00
parent 458dbf5e47
commit 0ede4df37e
1 changed files with 10 additions and 80 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

90
etc/MAILINGLISTS
View file

@ -19,24 +19,6 @@ gnu.emacs.help; gnu-emacs-sources, to gnu.emacs.sources. Replacing
`emacs' with some other program in those four examples shows you
the whole pattern.
If you don't know if your site is on USENET, ask your system
administrator. If you are a USENET site and don't get the gnu.all
newsgroups, please ask your USENET administrator to get them. If he has
your feeds ask their feeds, you should win. And everyone else wins:
newsgroups make better use of the limited bandwidth of the computer
networks and your home machine than mailing list traffic; and staying
off the mailing lists make better use of the people who maintain the
lists and the machines that the GNU people working with rms use (i.e. we
have more time to produce code!!). Thanx.
* Getting the mailing lists directly
If several users at your site or local network want to read a list and
you aren't a USENET site, Project GNU would prefer that you would set up
one address that redistributes locally. This reduces overhead on our
people and machines, your gateway machine, and the network(s) used to
transport the mail from us to you.
* How to subscribe to and report bugs in mailing lists
Send requests to be added or removed, to help-gnu-emacs-request (or
@ -48,8 +30,7 @@ If you need to report problems to a human, send mail to gnu@gnu.org
explaining the problem.
Many of the GNU mailing lists are very large and are received by many
people. Most are unmoderated, so please don't send them anything that
is not seriously important to all their readers.
people.
If a message you mail to a list is returned from a MAILER-DAEMON (often
with the line:
@ -72,25 +53,11 @@ activities in Cambridge and elsewhere can be directed to:
* General Information about all lists
Please keep each message under 25,000 characters. Some mailers bounce
messages that are longer than this. If your message is long, it is
generally better to send a message offering to make the large file
available to only those people who want it (e.g. mailing it to people
who ask, or putting it up for FTP). In the case of gnu.emacs.sources,
somewhat larger postings (up to 10 parts of no more than 25,000
characters each) are acceptable (assuming they are likely to be of
interest to a reasonable number of people); if it is larger than that,
put it in a web page and announce its URL. Good bug reports are short.
Do not send very large files to mailing lists; instead put then on a web
page and announce the URL. Good bug reports are short.
See section '* General Information about bug-* lists and ...' for
further details.
Most of the time, when you reply to a message sent to a list, the reply
should not go to the list. But most mail reading programs supply, by
default, all the recipients of the original as recipients of the reply.
Make a point of deleting the list address from the header when it does
not belong. This prevents bothering all readers of a list, and reduces
network congestion.
The GNU mailing lists and newsgroups, like the GNU project itself, exist
to promote the freedom to share software. So don't use these lists to
promote or recommend non-free software or documentation, like
@ -137,8 +104,8 @@ See section '* General Information about all lists'.
If you think something is a bug in a program, it might be one; or, it
might be a misunderstanding or even a feature. Before beginning to
report bugs, please read the section ``Reporting Emacs Bugs'' toward the
end of the GNU Emacs reference manual (or node Emacs/Bugs in Emacs's
report bugs, please read the section ``Reporting Bugs'' in
the GNU Emacs reference manual (or node Bugs in Emacs's
built-in Info system) for a discussion of how and when to send in bug
reports. For GNU programs other than GNU Emacs, also consult their
documentation for their bug reporting procedures. Always include the
@ -168,7 +135,7 @@ overworked; they don't have time to help individuals and still fix the
bugs and make the improvements that everyone wants. If you want help
for yourself in particular, you may have to hire someone. The GNU
project maintains a list of people providing such services. It is
found in <URL:http://www.gnu.org/prep/SERVICE>.
found at <URL:http://www.fsf.org/resources/service>.
Anything addressed to the implementers and maintainers of a GNU program
via a bug-* list, should NOT be sent to the corresponding info-* or
@ -234,48 +201,11 @@ unless they are made by someone you know is well connected with GNU and
are sure the message is not forged.
USENET and gnUSENET readers are expected to have read ALL the articles
in news.announce.newusers before posting. If news.announce.newusers is
empty at your site, wait (the articles are posted monthly), your posting
isn't that urgent! Readers on the Internet can anonymous FTP these
articles from host ftp.uu.net under directory ??
in news.announce.newusers before posting.
Remember, "GNUs Not Unix" and "gnUSENET is Not USENET". We have
higher standards!
** guile-sources-request@gnu.org to subscribe to guile-sources
gnUSENET newsgroup: NONE PLANNED
Guile source code to: guile-sources@gnu.org
This list will be for the posting, by their authors, of GUILE, Scheme,
and C sources and patches that improve Guile. Its contents will be
reviewed by the FSF for inclusion in future releases of GUILE.
Please do NOT discuss or request source code here. Use bug-guile for
those purposes. This allows the automatic archiving of sources posted
to this list.
Please do NOT post such sources to any other GNU mailing list (e.g
bug-guile) or gnUSENET newsgroups. It's up to each poster to decide
whether to cross-post to any non-gnUSENET newsgroup.
Please do NOT announce that you have posted source code to guile.sources
to any other GNU mailing list (e.g. bug-guile) or gnUSENET newsgroups.
People who want to keep up with sources will read this list. It's up to
each poster to decide whether to announce a guile.sources article in any
non-gnUSENET newsgroup (e.g. comp.emacs or comp.sources.d).
If source or patches that were previously posted or a simple fix is
requested in bug-guile, please mail it to the requester. Do NOT
repost it. If you also want something that is requested, send mail to
the requester asking him to forward it to you. This kind of traffic is
best handled by e-mail, not by a broadcast medium that reaches millions
of sites.
If the requested source is very long (>10k bytes) send mail offering to
send it. This prevents the requester from getting many redundant copies
and saves network bandwidth.
** gnu-emacs-sources-request@gnu.org to subscribe to gnu-emacs-sources
gnUSENET newsgroup: gnu.emacs.sources
@ -293,14 +223,14 @@ automatic archiving of sources posted to this list/newsgroup.
Please do NOT post such sources to any other GNU mailing list (e.g
help-gnu-emacs) or gnUSENET newsgroups (e.g. gnu.emacs.help). It's up
to each poster to decide whether to cross-post to any non-gnUSENET
newsgroup (e.g. comp.emacs or vmsnet.sources).
newsgroup (e.g. comp.emacs).
Please do NOT announce that you have posted source code to
gnu.emacs.sources to any other GNU mailing list (e.g. help-gnu-emacs) or
gnUSENET newsgroups (e.g. gnu.emacs.help). People who want to keep up
with sources will read this list/newsgroup. It's up to each poster to
decide whether to announce a gnu.emacs.sources article in any
non-gnUSENET newsgroup (e.g. comp.emacs or comp.sources.d).
non-gnUSENET newsgroup (e.g. comp.emacs).
If source or patches that were previously posted or a simple fix is
requested in help-gnu-emacs, please mail it to the requester. Do NOT
@ -309,7 +239,7 @@ the requester asking him to forward it to you. This kind of traffic is
best handled by e-mail, not by a broadcast medium that reaches millions
of sites.
If the requested source is very long (>10k bytes) send mail offering to
If the requested source is very long, send mail offering to
send it. This prevents the requester from getting many redundant copies
and saves network bandwidth.