This is the mail archive of the
mailing list for the GCC project.
Re: [Patch] Remove gccbug from bugreport.texi
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Wolfgang Bangerth <bangerth at ices dot utexas dot edu>
- Cc: gcc-patches at gcc dot gnu dot org, Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>
- Date: Tue, 13 May 2003 08:02:51 +0100 (BST)
- Subject: Re: [Patch] Remove gccbug from bugreport.texi
- References: <Pine.LNX.email@example.com>
On Mon, 12 May 2003, Wolfgang Bangerth wrote:
> (I'll probably get flamed for this...)
> The last sentence of the second last paragraph of bugreport.texi has two
> typos and one grammar error. I used this to get rid of the note about
> gccbug entirely. Everyone has WWW access these days, and my observation is
> that bugs sent in by gccbug are oftentimes missing something (but instead
> still have the default values of fields in them), so why not deprecate its
> use right away.
> Major objections?
There are large parts of the world where the normal (or only available)
form of network access is dialup, charged by the minute, so WWW bug
reporting is significantly more expensive for those users than composing a
message with gccbug offline.
However, bugreport.texi should be gutted so that it only refers to the
online bug reporting instructions _and to the copy of them included in the
distribution_ (for those normally working offline). This involves going
through it working out exactly what duplicates the online documentation
and what needs merging into it. Much the same applies to the Fortran
documentation which you noted previously. I don't think discussion of
particular bug reporting methods in the manual is an appropriate start.
Bug reports submitted through GNATSweb are often missing something as well
- the version number, or the attachment (through the submit defective bug
report / error comes back but for security the attachment needs to be made
manually on the form again route?). But it may make sense to write a new
gccbug (or use any such script already written elsewhere) that uses the
more functional Bugzilla email interface and supports attachments.
Joseph S. Myers