🚀 go-pugleaf

I got the following rejected mail.  I dont know whether my mail was
sent through anyway, so I am mailing to the -request address.

dan
---
>From MAILER-DAEMON@aeneas.MIT.EDU Thu Sep  3 13:31:09 1992
Received: from a.cs.uiuc.edu by spruce.cs.uiuc.edu with SMTP id AA29530
  (5.64+/IDA-1.3.4 for liberte); Thu, 3 Sep 92 13:31:08 -0500
Received: from AENEAS.MIT.EDU by a.cs.uiuc.edu with SMTP id AA15389
  (5.64+/IDA-1.3.4 for liberte@spruce.cs.uiuc.edu); Thu, 3 Sep 92 13:31:04 -0500
Received: from a.cs.uiuc.edu by aeneas.MIT.EDU (5.61/4.7) id AA22646; Thu, 3 Sep 92 14:29:29 -0400
Date: Thu, 3 Sep 92 14:29:29 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON@aeneas.MIT.EDU>
Subject: Returned mail: User unknown
Message-Id: <9209031829.AA22646@aeneas.MIT.EDU>
To: <liberte@cs.uiuc.edu>
Status: RO

   ----- Transcript of session follows -----
>>> RCPT To:<help-gnu-emacs@prep.AI.MIT.EDU>
<<< 550 <help-gnu-emacs@prep.AI.MIT.EDU>... User unknown
550 <help-gnu-emacs@prep.ai.mit.edu>... User unknown

   ----- Unsent message follows -----
Received: from a.cs.uiuc.edu by aeneas.MIT.EDU (5.61/4.7) id AA22644; Thu, 3 Sep 92 14:29:29 -0400
Received: from birch.cs.uiuc.edu by a.cs.uiuc.edu with SMTP id AA15296
  (5.64+/IDA-1.3.4 for help-gnu-emacs@prep.ai.mit.edu); Thu, 3 Sep 92 13:28:04 -0500
Message-Id: <9209031828.AA15296@a.cs.uiuc.edu>
Received: by birch.cs.uiuc.edu
	(5.64+/15.6) id AA03782; Thu, 3 Sep 92 13:28:03 -0500
Date: Thu, 3 Sep 92 13:28:03 -0500
From: liberte@cs.uiuc.edu
To: help-gnu-emacs@prep.ai.mit.edu
Subject: Emacs bugs
Cc: liberte@cs.uiuc.edu

	From: rms@gnu.ai.mit.edu (Richard Stallman)

	Have you sent a bug report with a detailed recipe for reproducing the
	problem?  If not, please do--so we can get it *fixed*.

	Users often treat bugs as immutable facts of nature; they talk about
	what bugs exist as if they just had to learn to live with them or
	avoid them.

There are several reasons that bugs don't get reported.  I suggest some
remedies.

1. It may difficult to tell whether something is a bug or some
kind of weird feature.  But if emacs crashes or hangs, this is clearly
a bug.  Weird features can be considered bugs if there is no good
reason for them, but that is often difficult to tell without experience.
If the printed documentation differs from the on-line
documentation, or from Emacs' behavior, there is a bug in one of them.

2. It may be a bug in some non-standard package or modification of Emacs.  
Non-standard modifications of Emacs should be clearly indicated to users.
Go to the author of the modifications first if they are at all suspect.
Non-standard packages should be used with some caution, particularly those
that modify standard behavior.  Package writers should avoid such
modifications and generally warn users of potential problems or
known bugs.

3. It may be difficult to identify or reproduce a bug.  Experience helps
alot here.  Emacs provides some utilities that help, but there is room for
more.  

4. It takes time and effort to put together a bug report, even
after identifying the bug.  If the reason for the bug is not clear,
part of the problem is identifying enough of the environment so others
can reproduce the problem.  Utilities can help here.

5. It may have already been reported, so why should I bother? 
A known bug list would help.  With each distribution, include the
list in the etc directory with a reference to the ftpable file for
the current list.

Emacs maintainers shouldn't object too strongly to getting vague
rumors of bugs.  That may be the most that some users can offer
for various reasons.  Discouraging vague reports is just discouraging.
Instead, encourage users by making it easier.

Dan LaLiberte
liberte@cs.uiuc.edu
(Join the League for Programming Freedom: league@prep.ai.mit.edu)