os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Small spelling fixes and added myself to contact.sgml.

Browse source 
Totally un-reviewed!
This commit is contained in:
Maxim Sobolev 2002-01-22 22:44:40 +00:00
parent 53c612b228
commit daa57a6143
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=11828
3 changed files with 12 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

12
en/gnome/docs/bugging.sgml
View file

@ -18,14 +18,14 @@
<p>The rule of the thumb should be: report as much information as you
can, because even if there is some irrelevant information usually
developers could quite easy filter it out. On contrary, situation is
much worse when there is too little informaton to reliably track down
or reproduce the problem - in this case developers have to speend their
much worse when there is too little information to reliably track down
or reproduce the problem - in this case developers have to spend their
time guessing and/or asking originator of report to send more
information.</p>
<p>There are plenty of examples of totally useless bug reports, something
like <i>"Hey, gnomefoo port is broken. I'm running FreeBSD-X.Y.
Please fix."</i> Nedless to say, that such report is just a waste of
Please fix."</i> Needless to say, that such report is just a waste of
your time, time of the appropriate developer and network bandwidth.
At the bare minimum the report should include the following
information:</p>
@ -39,11 +39,11 @@
last time updating your ports tree.</p></li>
<li><p>Information specific for each type of breakage: full log of
unsuccessful build in the case when the build of the port is broken,
stack trace in the case of coredump, clean and detailed description
stack trace in the case of core dump, clean and detailed description
of the problem when application does something unexpected etc. Try
to put yourself into developer's shoes and in each particular case
evaluate what information would be necessary for him to locate the
source of the problem, don't just assume that he alredy knows all
source of the problem, don't just assume that he already knows all
about the problem, but is just too lazy to fix it.</p></li>
</ul>
@ -76,7 +76,7 @@
readily available solution then report to the developers of the
software directly (for most core GNOME components this means that you
need to use their Bugzilla bug tracking system).</p></li>
<li><p>If the proble isn't a FreeBSD-specific, but quite serious and you
<li><p>If the problem isn't a FreeBSD-specific, but quite serious and you
have a fix available then report both to FreeBSD and authors' bug
tracking systems, so that the appropriate port will be patched and
other users of FreeBSD will be able to benefit from your fix, without