1 GNU Project Electronic Mailing Lists and gnUSENET Newsgroups
2 Last Updated 2004-10-19
4 Please report improvements to: gnu@gnu.org
6 * Mailing list archives
8 The GNU mailing lists are archived at http://lists.gnu.org.
10 * Some GNU mailing lists are also distributed as USENET news groups
12 Certain GNU mailing lists are gated both ways with the gnu.all
13 newsgroups at uunet. You can tell which they are, because the names
14 correspond. For instance, bug-gnu-emacs corresponds to gnu.emacs.bug;
15 info-gnu-emacs, to gnu.emacs.announce; help-gnu-emacs, to
16 gnu.emacs.help; gnu-emacs-sources, to gnu.emacs.sources. Replacing
17 `emacs' with some other program in those four examples shows you
20 If you don't know if your site is on USENET, ask your system
21 administrator. If you are a USENET site and don't get the gnu.all
22 newsgroups, please ask your USENET administrator to get them. If he has
23 your feeds ask their feeds, you should win. And everyone else wins:
24 newsgroups make better use of the limited bandwidth of the computer
25 networks and your home machine than mailing list traffic; and staying
26 off the mailing lists make better use of the people who maintain the
27 lists and the machines that the GNU people working with rms use (i.e. we
28 have more time to produce code!!). Thanx.
30 * Getting the mailing lists directly
32 If several users at your site or local network want to read a list and
33 you aren't a USENET site, Project GNU would prefer that you would set up
34 one address that redistributes locally. This reduces overhead on our
35 people and machines, your gateway machine, and the network(s) used to
36 transport the mail from us to you.
38 * How to subscribe to and report bugs in mailing lists
40 Send requests to be added or removed, to help-gnu-emacs-request (or
41 info-gnu-request, bug-gdb-request, etc.), NOT to info-gnu-emacs (or
42 info-gnu, etc.). Most <LIST_NAME>-request addresses are now handled
43 automagically by GNU Mailman.
45 If you need to report problems to a human, send mail to gnu@gnu.org
46 explaining the problem.
48 Many of the GNU mailing lists are very large and are received by many
49 people. Most are unmoderated, so please don't send them anything that
50 is not seriously important to all their readers.
52 If a message you mail to a list is returned from a MAILER-DAEMON (often
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.
62 It is appropriate to send these to the -request address for a list, and
63 ask them to check the problem out.
65 * Send Specific Requests for Information to: gnu@gnu.org
67 Specific requests for information about obtaining GNU software, or GNU
68 activities in Cambridge and elsewhere can be directed to:
71 * General Information about all lists
73 Please keep each message under 25,000 characters. Some mailers bounce
74 messages that are longer than this. If your message is long, it is
75 generally better to send a message offering to make the large file
76 available to only those people who want it (e.g. mailing it to people
77 who ask, or putting it up for FTP). In the case of gnu.emacs.sources,
78 somewhat larger postings (up to 10 parts of no more than 25,000
79 characters each) are acceptable (assuming they are likely to be of
80 interest to a reasonable number of people); if it is larger than that,
81 put it in a web page and announce its URL. Good bug reports are short.
82 See section '* General Information about bug-* lists and ...' for
85 Most of the time, when you reply to a message sent to a list, the reply
86 should not go to the list. But most mail reading programs supply, by
87 default, all the recipients of the original as recipients of the reply.
88 Make a point of deleting the list address from the header when it does
89 not belong. This prevents bothering all readers of a list, and reduces
92 The GNU mailing lists and newsgroups, like the GNU project itself, exist
93 to promote the freedom to share software. So don't use these lists to
94 promote or recommend non-free software or documentation, like
95 proprietary books on GNU software. (Using them to post ordering
96 information is the ultimate faux pas.) If there is no free program to
97 do a certain task, then somebody should write one! Similarly, free
98 documentation that is inadequate should be improved--a way in which
99 non-programmers can make a valuable contribution. See also the article
100 at <URL:http://www.gnu.org/philosophy/free-doc.html>.
102 * General Information about info-* lists
104 These lists and their newsgroups are meant for important announcements.
105 Since the GNU project uses software development as a means for social
106 change, the announcements may be technical or political.
108 Most GNU projects info-* lists (and their corresponding gnu.*.announce
109 newsgroups) are moderated to keep their content significant and
110 relevant. If you have a bug to report, send it to the bug-* list. If
111 you need help on something else and the help-* list exists, ask it.
113 See section '* General Information about all lists'.
115 * General Information about help-* lists
117 These lists (and their newsgroups) exist for anyone to ask questions
118 about the GNU software that the list deals with. The lists are read by
119 people who are willing to take the time to help other users.
121 When you answer the questions that people ask on the help-* lists, keep
122 in mind that you shouldn't answer by promoting a proprietary program as
123 a solution. The only real solutions are the ones all the readers can
126 If a program crashes, or if you build it following the standard
127 procedure on a system on which it is supposed to work and it does not
128 work at all, or if an command does not behave as it is documented to
129 behave, this is a bug. Don't send bug reports to a help-* list; mail
130 them to the bug-* list instead.
132 See section '* General Information about all lists'.
134 * General Information about bug-* lists and reporting program bugs
136 If you think something is a bug in a program, it might be one; or, it
137 might be a misunderstanding or even a feature. Before beginning to
138 report bugs, please read the section ``Reporting Emacs Bugs'' toward the
139 end of the GNU Emacs reference manual (or node Emacs/Bugs in Emacs's
140 built-in Info system) for a discussion of how and when to send in bug
141 reports. For GNU programs other than GNU Emacs, also consult their
142 documentation for their bug reporting procedures. Always include the
143 version number of the GNU program, as well as the operating system and
144 machine the program was ran on (if the program doesn't have a version
145 number, send the date of the latest entry in the file ChangeLog). For
146 GNU Emacs bugs, type "M-x emacs-version". A debugger backtrace of any
147 core dump can also be useful. Be careful to separate out hypothesis
148 from fact! For bugs in GNU Emacs lisp, set variable debug-on-error to
149 t, and re-enter the command(s) that cause the error message; Emacs will
150 pop up a debug buffer if something is wrong; please include a copy of
151 the buffer in your bug report. Please also try to make your bug report
152 as short as possible; distill the problem to as few lines of code and/or
153 input as possible. GNU maintainers give priority to the shortest, high
156 Please don't send in a patch without a test case to illustrate the
157 problem the patch is supposed to fix. Sometimes the patches aren't
158 correct or aren't the best way to do the job, and without a test case
159 there is no way to debug an alternate fix.
161 The purpose of reporting a bug is to enable the bug to be fixed for the
162 sake of the whole community of users. You may or may not receive a
163 response; the maintainers will send one if that helps them find or
164 verify a fix. Most GNU maintainers are volunteers and all are
165 overworked; they don't have time to help individuals and still fix the
166 bugs and make the improvements that everyone wants. If you want help
167 for yourself in particular, you may have to hire someone. The GNU
168 project maintains a list of people providing such services. It is
169 found in <URL:http://www.gnu.org/prep/SERVICE>.
171 Anything addressed to the implementors and maintainers of a GNU program
172 via a bug-* list, should NOT be sent to the corresponding info-* or
175 Please DON'T post your bug reports on the gnu.*.bug newsgroups! Mail
176 them to bug-*@gnu.org instead! At first sight, it seems to make no
177 difference: anything sent to one will be propagated to the other; but:
178 - if you post on the newsgroup, the information about how to
179 reach you is lost in the message that goes on the mailing list. It
180 can be very important to know how to reach you, if there is anything
181 in the bug report that we don't understand;
182 - bug reports reach the GNU maintainers quickest when they are
183 sent to the bug-* mailing list submittal address;
184 - mail is much more reliable then netnews; and
185 - if the internet mailers can't get your bug report delivered,
186 they almost always send you an error message, so you can find another
187 way to get the bug report in. When netnews fails to get your message
188 delivered to the maintainers, you'll never know about it and the
189 maintainers will never see the bug report.
191 And please DON'T post your GNU bug reports to comp.* or other gnu.*
192 newsgroups, they never make it to the GNU maintainers at all. Please
193 mail them to bug-*@gnu.org instead!
195 * Some special lists that don't fit the usual patterns of help-, bug- and info-
197 ** info-gnu-request@gnu.org to subscribe to info-gnu
199 gnUSENET newsgroup: gnu.announce
200 Send announcements to: info-gnu@gnu.org
202 This list distributes progress reports on the GNU Project. It is also
203 used by the GNU Project to ask people for various kinds of help. It is
204 moderated and NOT for general discussion.
206 ** gnu-misc-discuss-request@gnu.org to subscribe to gnu-misc-discuss
208 gnUSENET newsgroup: gnu.misc.discuss
209 Send contributions to: gnu-misc-discuss@gnu.org
211 This list is for serious discussion of free software, the GNU Project,
212 the GNU Manifesto, and their implications. It's THE place for
213 discussion that is not appropriate in the other GNU mailing lists and
216 Flaming is out of place. Tit-for-tat is not welcome. Repetition
219 Good READING and writing are expected. Before posting, wait a while,
222 Don't use this group for complaints and bug reports about GNU software!
223 The maintainers of the package you are using probably don't read this
224 group; they won't see your complaint. Use the appropriate bug-reporting
225 mailing list instead, so that people who can do something about the
226 problem will see it. Likewise, use the help- list for technical
229 Don't trust pronouncements made on gnu-misc-discuss about what GNU is,
230 what FSF position is, what the GNU General Public License is, etc.,
231 unless they are made by someone you know is well connected with GNU and
232 are sure the message is not forged.
234 USENET and gnUSENET readers are expected to have read ALL the articles
235 in news.announce.newusers before posting. If news.announce.newusers is
236 empty at your site, wait (the articles are posted monthly), your posting
237 isn't that urgent! Readers on the Internet can anonymous FTP these
238 articles from host ftp.uu.net under directory ??
240 Remember, "GNUs Not Unix" and "gnUSENET is Not USENET". We have
243 ** guile-sources-request@gnu.org to subscribe to guile-sources
245 gnUSENET newsgroup: NONE PLANNED
246 Guile source code to: guile-sources@gnu.org
248 This list will be for the posting, by their authors, of GUILE, Scheme,
249 and C sources and patches that improve Guile. Its contents will be
250 reviewed by the FSF for inclusion in future releases of GUILE.
252 Please do NOT discuss or request source code here. Use bug-guile for
253 those purposes. This allows the automatic archiving of sources posted
256 Please do NOT post such sources to any other GNU mailing list (e.g
257 bug-guile) or gnUSENET newsgroups. It's up to each poster to decide
258 whether to cross-post to any non-gnUSENET newsgroup.
260 Please do NOT announce that you have posted source code to guile.sources
261 to any other GNU mailing list (e.g. bug-guile) or gnUSENET newsgroups.
262 People who want to keep up with sources will read this list. It's up to
263 each poster to decide whether to announce a guile.sources article in any
264 non-gnUSENET newsgroup (e.g. comp.emacs or comp.sources.d).
266 If source or patches that were previously posted or a simple fix is
267 requested in bug-guile, please mail it to the requester. Do NOT
268 repost it. If you also want something that is requested, send mail to
269 the requester asking him to forward it to you. This kind of traffic is
270 best handled by e-mail, not by a broadcast medium that reaches millions
273 If the requested source is very long (>10k bytes) send mail offering to
274 send it. This prevents the requester from getting many redundant copies
275 and saves network bandwidth.
277 ** gnu-emacs-sources-request@gnu.org to subscribe to gnu-emacs-sources
279 gnUSENET newsgroup: gnu.emacs.sources
280 GNU Emacs source code to: gnu-emacs-sources@gnu.org
282 This list/newsgroup will be for the posting, by their authors, of Emacs
283 Lisp and C sources and patches that improve GNU Emacs. Its contents
284 will be reviewed by the FSF for inclusion in future releases of GNU
287 Please do NOT discuss or request source code here. Use
288 help-gnu-emacs/gnu.emacs.help for those purposes. This allows the
289 automatic archiving of sources posted to this list/newsgroup.
291 Please do NOT post such sources to any other GNU mailing list (e.g
292 help-gnu-emacs) or gnUSENET newsgroups (e.g. gnu.emacs.help). It's up
293 to each poster to decide whether to cross-post to any non-gnUSENET
294 newsgroup (e.g. comp.emacs or vmsnet.sources).
296 Please do NOT announce that you have posted source code to
297 gnu.emacs.sources to any other GNU mailing list (e.g. help-gnu-emacs) or
298 gnUSENET newsgroups (e.g. gnu.emacs.help). People who want to keep up
299 with sources will read this list/newsgroup. It's up to each poster to
300 decide whether to announce a gnu.emacs.sources article in any
301 non-gnUSENET newsgroup (e.g. comp.emacs or comp.sources.d).
303 If source or patches that were previously posted or a simple fix is
304 requested in help-gnu-emacs, please mail it to the requester. Do NOT
305 repost it. If you also want something that is requested, send mail to
306 the requester asking him to forward it to you. This kind of traffic is
307 best handled by e-mail, not by a broadcast medium that reaches millions
310 If the requested source is very long (>10k bytes) send mail offering to
311 send it. This prevents the requester from getting many redundant copies
312 and saves network bandwidth.
319 arch-tag: 6e42bba8-7532-4a23-8486-99dbc5770a8e