home *** CD-ROM | disk | FTP | other *** search
/ Fresh Fish 2 / FFMCD02.bin / useful / lib / emacs / 18.59 / etc / mailinglists < prev    next >
Text File  |  1992-02-16  |  31KB  |  744 lines
  1.      GNU Project Electronic Mailing Lists.  Last Updated 23 Oct 91
  2.  
  3.        Please report improvements to: gnu@prep.ai.mit.edu
  4.  
  5. * GNU mailing lists are also distributed as USENET news groups
  6.  
  7. The mailing lists are gated both ways with the gnu.all newsgroups at
  8. ohio-state.edu.  The one-to-one correspondence is indicated below.  If
  9. you don't know if your site is on USENET, ask your system administrator.
  10. If you are a USENET site and don't get the gnu.all newsgroups, please
  11. ask your USENET administrator to get them.  If he has your feeds ask
  12. their feeds, you should win.  And everyone else wins: newsgroups make
  13. better use of the limited bandwidth of the computer networks and your
  14. home machine than mailing list traffic; and staying off the mailing
  15. lists make better use of the people who maintain the lists and the
  16. machines that the GNU people working with rms use (i.e. we have more
  17. time to produce code!!).  Thanx.
  18.  
  19. * Getting the mailing lists directly
  20.  
  21. If several users at your site or local network want to read a list and
  22. you aren't a USENET site, Project GNU would prefer that you would set up
  23. one address that redistributes locally.  This reduces overhead on our
  24. people and machines, your gateway machine, and the network(s) used to
  25. transport the mail from us to you.
  26.  
  27. * How to subscribe to and report bugs in mailing lists
  28.  
  29. Send messages ABOUT these lists, such as reports of mail problems, or
  30. requests to be added or removed, to help-gnu-emacs-request (or
  31. info-gnu-request, bug-gdb-request, etc.), NOT to info-gnu-emacs (or
  32. info-gnu, etc.).  These <LIST_NAME>-request addresses go only to the
  33. people who can do something about your requests or problems, and thus
  34. avoids disturbing everyone else.
  35.  
  36. Note that all GNU mailing lists are maintained by volunteers.  They get
  37. behind occasionally.  Wait at least 3 or 4 days before asking again.
  38. Thanks!
  39.  
  40. Many of the GNU mailing lists are very large and are received by many
  41. people.  Please don't send them anything that is not seriously important
  42. to all their readers.  All GNU mailing lists are unmoderated, mail
  43. reflectors, except info-gnu, info-gnu-emacs, info-gcc, info-g++ and
  44. info-gnu-fortran.
  45.  
  46. All addresses below are in internet format.  Consult the mail guru for
  47. your computer to figure out address syntaxes from other networks.  From
  48. UUCP machines:
  49.     ..!ucbvax!prep.ai.mit.edu!ADDRESS
  50.     ..!uunet!prep.ai.mit.edu!ADDRESS
  51.  
  52. If a message you mail to a list is returned from a MAILER-DAEMON (often
  53. with the line:
  54.       ----- Transcript of session follows -----
  55.  don't resend the message to the list.  All this return means is that
  56. your original message failed to reach a few addresses on the list.  Such
  57. messages are NEVER a reason to resend a piece of mail a 2nd time.  This
  58. just bothers all (less the few delivery failures (which will probably
  59. just fail again!)) of the readers of the list with a message they have
  60. already seen.  It also wastes computer and network resources.
  61.  
  62. It is appropriate to send these to the -request address for a list, and
  63. ask them to check the problem out.
  64.  
  65. * Send Specific Requests for Information to: gnu@prep.ai.mit.edu
  66.  
  67. Specific requests for information about obtaining GNU software, or GNU
  68. activities in Cambridge and elsewhere can be directed to:
  69.     gnu@prep.ai.mit.edu
  70.  
  71. * General Information about all lists
  72.  
  73. Please keep each message under 40,000 characters.  Some mailers bounce
  74. messages that are longer than this.
  75.  
  76. Most of the time, when you reply to a message sent to a list, the reply
  77. should not go to the list.  But most mail reading programs supply, by
  78. default, all the recipients of the original as recipients of the reply.
  79. Make a point of deleting the list address from the header when it does
  80. not belong.  This prevents bothering all readers of a list, and reduces
  81. network congestion.
  82.  
  83. The GNU mailing lists and newsgroups, like the GNU project itself, exist
  84. to promote the freedom to share software.  So don't use these lists to
  85. promote or recommend non-free software.  (Using them to post ordering
  86. information is the ultimate faux pas.)  If there is no free program to
  87. do a certain task, then somebody should write one!
  88.  
  89. * General Information about info-* lists
  90.  
  91. These lists and their newsgroups are meant for important announcements.
  92. Since the GNU project uses software development as a means for social
  93. change, the announcements may be technical or political.
  94.  
  95. Most GNU projects info-* lists (and their corresponding gnu.*.announce
  96. newsgroups) are moderated to keep their content significant and
  97. relevant.  If you have a bug to report, send it to the bug-* list.  If
  98. you need help on something else and the help-* list exists, ask it.
  99.  
  100. See section '* General Information about all lists'.
  101.  
  102. * General Information about help-* lists
  103.  
  104. These lists (and their newsgroups) exist for anyone to ask questions
  105. about the GNU software that the list deals with.  The lists are read by
  106. people who are willing to take the time to help other users.
  107.  
  108. When you answer the questions that people ask on the help-* lists, keep
  109. in mind that you shouldn't answer by promoting a proprietary program as
  110. a solution.  The only real solutions are the ones all the readers can
  111. share.
  112.  
  113. See section '* General Information about all lists'.
  114.  
  115. * General Information about bug-* lists and reporting program bugs
  116.  
  117. If you think something is a bug in a program, it might be one; or, it
  118. might be a misunderstanding or even a feature.  Before beginning to
  119. report bugs, please read the section ``Reporting Emacs Bugs'' toward the
  120. end of the GNU Emacs reference manual (or node Emacs/Bugs in Emacs's
  121. built-in Info system) for a discussion of how and when to send in bug
  122. reports.  For GNU programs other than GNU Emacs, also consult their
  123. documentation for their bug reporting procedures.  Always include the
  124. version number of the GNU program, as well as the operating system and
  125. machine the program was ran on (if the program doesn't have a version
  126. number, send the date of the latest entry in the file ChangeLog).  For
  127. GNU Emacs bugs, type "M-x emacs-version".  A debugger backtrace of any
  128. core dump, can also be useful.  Be careful to separate out hypothesis
  129. from fact!  For bugs in GNU Emacs lisp, set variable debug-on-error to
  130. t, and re-enter the command(s) that cause the error message; Emacs will
  131. pop up a debug buffer if something is wrong; please include a copy of
  132. the buffer in your bug report.
  133.  
  134. Please don't send in a patch without a test case to illustrate the
  135. problem the patch is supposed to fix.  Sometimes the patches aren't
  136. correct or aren't the best way to do the job, and without a test case
  137. there is no way to debug an alternate fix.
  138.  
  139. The purpose of reporting a bug is to enable the bug to be fixed for the
  140. sake of the whole community of users.  You may or may not receive a
  141. response; the maintainers will send one if that helps them find or
  142. verify a fix.  Most GNU maintainers are volunteers and all are
  143. overworked; they don't have time to help individuals and still fix the
  144. bugs and make the improvements that everyone wants.  If you want help
  145. for yourself in particular, you may have to hire someone.  The GNU
  146. project maintains a list of people providing such services.  It is
  147. distributed with GNU Emacs in file etc/SERVICE, and can be requested
  148. from gnu@prep.ai.mit.edu.
  149.  
  150. Anything addressed to the implementors and maintainers of a GNU program
  151. via a bug-* list, should NOT be sent to the corresponding info-* or
  152. help-* list.
  153.  
  154. Please DON'T post your bug reports on the gnu.* newsgroups!  Mail them
  155. to bug-*@prep instead!  At first sight, it seems to make no difference:
  156. anything sent to one will be propagated to the other; but if you post on
  157. the newsgroup, the information about how to reach you is lost in the
  158. message that goes on the mailing list.  It can be very important to know
  159. how to reach you if there is anything in the bug report that we don't
  160. understand.  Bug reports also reach the GNU maintainers quickest when
  161. they are sent to the bug-* mailing list submittal address.
  162.  
  163. And please DON'T post your GNU bug reports to comp.* or other non gnu.*
  164. newsgroups, they never make it to the GNU maintainers at all.  Please
  165. mail them to bug-*@prep instead!
  166.  
  167. See section '* General Information about all l