`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
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:
* 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
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
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
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
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
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.
HCoop / bpt / emacs.git / commitdiff