Re: Updating bug reporting request error messages and docs to gcc.gnu.org

[Alexandre Oliva <oliva@dcc.unicamp.br>]

On Jul 17, 1999, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:

> On 17 Jul 1999, Alexandre Oliva wrote:
>> The patch below updates all occurrences of egcs-bugs in the gcc
>> sources to refer only to the bug reporting FAQ, so that we (hopefully)
>> get better-quality bug reports.

> Yes, yes, yes, pleeease!

Uhh, I don't think I can take this as an approval :-)

But here's one you can approve.  :-) It adds a couple of paragraphs
with some details I've had to repeat to many bug reporters along the
last few months.

Index: faq.html
===================================================================
RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/faq.html,v
retrieving revision 1.132
diff -u -r1.132 faq.html
--- faq.html	1999/07/16 13:14:00	1.132
+++ faq.html	1999/07/17 08:52:35
@@ -212,7 +212,7 @@
 <p>In short, if gcc says <tt>Internal compiler error</tt> (or any
 other error that you'd like us to be able to reproduce, for that
 matter), please mail a bug report to <a
-href="mailto:egcs-bugs@egcs.cygnus.com">egcs-bugs@egcs.cygnus.com</a> including:
+href="mailto:gcc-bugs@gcc.gnu.org">gcc-bugs@gcc.gnu.org</a> including:
 
 <ul>
   <li>The gcc version
@@ -230,17 +230,45 @@
 
 <p><tt>gcc -v --save-temps <i>all-your-options</i> <i>your-file</i>.c</tt>
 
-<p>Typically the CPP output will be large, so please compress the resulting
-file with one of the popular compression programs such as <tt>gzip</tt>,
-<tt>bzip2</tt>, <tt>compress</tt> or <tt>pkzip</tt>, then include the
-compressed CPP output as an attachment to your message.
+<p>Typically the CPP output will be large, so please compress (with
+maximum compression, <code>--best</code> or <code>-9</code>) the
+resulting file with one of the popular compression programs such as
+<tt>bzip2</tt>, <tt>gzip</tt>, <tt>zip</tt>, <tt>pkzip</tt> or
+<tt>compress</tt> (in decreasing order of preference), then include
+the compressed CPP output (extension <code>.i</code> for C or
+<code>.ii</code> for C++) in your message.  Since we're supposed to be
+able to re-create the assembly assembly output (extension
+<code>.s</code>), you don't usually have to include it in the bug
+report, although you may want to post parts of them to point out
+assembly code you consider to be wrong.
+
+<p>Whether to use MIME attachments or <code>uuencode</code> is up to
+you.  In any case, make sure the compiler command line, version and
+error output are in plain text, so that we don't have to decode the
+bug report in order to tell who should take care of it.  A meaningful
+subject, indicating the language and platform in which the bug
+occurred, also helps.
 
 <p>The gcc lists have message size limits (100 kbytes) and bug reports
 over those limits will currently be bounced.  We're trying to find a
 way to allow larger bug reports to be posted, but this is currently
-impossible.  So, although we prefer to have complete bug reports
-archived, if you cannot reduce the bug report below the limit, please
-make it available for ftp or http and post the URL.
+impossible (unless you use MIME partials, which most people are unable
+to handle anyway, so you'd better avoid them for now).  So, although
+we prefer to have complete bug reports archived, if you cannot reduce
+the bug report below the limit, please make it available for ftp or
+http and post the URL.  Another alternative is to break the
+preprocessed output in multiple files (using <code>split</code>, for
+example) and post them in separate messages, but we prefer to have
+self-contained bug reports in single messages.
+
+<p>If you fail to supply information enough information for a bug
+report to be reproduced, someone will probably ask you to post
+additional information.  In this case, please reply to the bug
+reporting mailing list, not just to the person who requested the
+information, unless explicitly told so.  If possible, please include
+in this follow-up all the information you had supplied in the
+incomplete bug report (including the preprocessor output), so that the
+new bug report is self-contained.
 
 <hr>
 <h2><a name="support">How do I get a bug fixed or a feature added?</a></h2>
@@ -292,7 +320,7 @@
 available.                                                               
 
 <hr>
-<h2><a name="multiple">How to install both multiple versions of gcc</a></h2>
+<h2><a name="multiple">How to install multiple versions of gcc</a></h2>
 <p>It may be desirable to install multiple versions of the compiler on
 the same system.  This can be done by using different prefix paths at
 configure time and a few symlinks.
@@ -1144,7 +1172,7 @@
 <hr>
 
 <p><a href="index.html">Return to the EGCS home page</a>
-<p><i>Last modified:  July 15, 1999</i>
+<p><i>Last modified:  July 17, 1999</i>
 
 </body>
 </html>

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them