[Emacs-diffs] trunk r115953: * etc/MAILINGLISTS: Remove the more extremely obsolete parts

[Glenn Morris]

------------------------------------------------------------
revno: 115953
revision-id: address@hidden
parent: address@hidden
committer: Glenn Morris <address@hidden>
branch nick: trunk
timestamp: Thu 2014-01-09 22:08:13 -0500
message:
  * etc/MAILINGLISTS: Remove the more extremely obsolete parts
modified:
  etc/MAILINGLISTS               
mailinglists-20091113204419-o5vbwnq5f7feedwu-1675

=== modified file 'etc/MAILINGLISTS'
--- a/etc/MAILINGLISTS  2014-01-01 07:43:34 +0000
+++ b/etc/MAILINGLISTS  2014-01-10 03:08:13 +0000
@@ -19,24 +19,6 @@
 `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 @@
 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 @@
 
 * 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 @@
 
 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 @@
 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 @@
 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!
 
-** address@hidden to subscribe to guile-sources
-
-gnUSENET newsgroup: NONE PLANNED
-Guile source code to: address@hidden
-
-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.
-
 ** address@hidden to subscribe to gnu-emacs-sources
 
 gnUSENET newsgroup: gnu.emacs.sources
@@ -293,14 +223,14 @@
 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 @@
 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.