This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: reporting bugs


On Sun, Jun 18, 2000 at 07:40:01PM +0200, Martin v. Loewis wrote:
> > Some time ago I posted a bug report with patch (that worked for me) but never
> > got any reply. Was my mail lost? Was the patch too bad/stupid/wrong/breaking
> > other stuff? Was the problem unclear? Or had the good guys just no time for
> > that particular problem?
> 
> It's hard to tell. If you really used the 'gccbug' script, then yes,
> you should have gotten an automatic confirmation, together with a PR
> report number. If you didn't, I really like to investigate this
> incident, as it is critical that the GNATS tracking really works.

Yes, I did use the gccbug script. And no, I never got a reply (not that I 
remember)
Now that I know that I should have received one, I assume that my mail was
lost. Unfortunately my submission was so long ago that I don't have the patches
around any more. So please excuse my complaint on this one.

(The problems in question were 32<->64 bit issues I found when I tried
bootstrapping my Alpha system by crosscompiling from Intel. Some function calls
actually passed parameters as long (32bit) when they should have used long long
(64bit). Sorry, I forgot the details :-( )

Perhaps you could explicitely mention the report confirmation in the docs.

> If, on the other hand, you merely sent a message to
> gcc-bugs@gcc.gnu.org, then you can't expect an automated response. As
> it turns out, you can't expect a human response, either, because of

Yes - I absolutely agree.

> 
> > $ info gcc
> > ->Bugs
> > -->Where: Bug Lists
> > --->Please read `<URL:http://www.gnu.org/software/gcc/bugs.html>' 
> > ---->Reporting Bugs - The gcc info manual, section Bugs contains complete instructions 
> > 
> > back to step 1   :-/
> 
> Well, reading the manual is the better choice. Most people don't, so
> the online version is a quick summary of the really crucial
> information that people should read even if they have never heard
> about info.

Ok - but don't point back to the online version then! I think it is ok to
say in the online version 'this is a summary, look into the info manual for
details'. It's just very irritating to be referred from the detailed version
to the summary. 

> > $ info gcc
> > ->Bugs
> > -->Reporting: Bug Reporting
> > --->You may find additional and/or more up-to-date instructions at
> >     `<URL:http://www.gnu.org/software/gcc/bugs.html>
> > you guess it:
> > ---->Reporting Bugs - The gcc info manual, section Bugs contains complete
> 
> As an intelligent being, I hope you won't process such instructions
> step-by-step, without any look-ahead whatsoever. Just read on.

More ore less: yes. But by the pure presence of that url you expect people
to actually look it up, don't you ;-) ?

> > I suggest electing one authorative set of documentation and removal
> > of the circular links.
> 
> The authorative source of information is the manual. Unfortunately, we

All I ask you is to make this explicit without uncertaincy.

> can't update the manual on each user's system, so we have to have more
> recent information on-line - like the existence of GNATS.

Well - if I download a recent gcc snapshot (or a 'stable' tarball) I expect
the documentation contained therein to be sufficiently up-to-date.

Please keep in mind that this is from the perspective of a gcc-user who 
never intended to do actual gcc develompent. As such one has to use the docs
somehow to find the most appropriate way to submit reports/patches. And itīs
annoying when there's no definitve answer to that question.

> Regards,
> Martin

Bye,
Thorsten
-- 
| Thorsten Kranzkowski        Internet: dl8bcu@gmx.net                        |
| Mobile: ++49 170 1876134       Snail: Niemannsweg 30, 49201 Dissen, Germany |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] |

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]