* Fix some grammar nits
* Clean up the formatting a bit
This commit is contained in:
Joe Marcus Clarke
parent
f56ae13adb
commit
bd68581963
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/www/; revision=14013
1 changed files with 49 additions and 45 deletions
|
|
@ -1,6 +1,6 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" [
|
||||
<!ENTITY base CDATA "../..">
|
||||
<!ENTITY date "$FreeBSD$">
|
||||
<!ENTITY date "$FreeBSD: www/en/gnome/docs/bugging.sgml,v 1.6 2002/02/04 06:50:41 sobomax Exp $">
|
||||
<!ENTITY title "FreeBSD GNOME Project: Reporting a Bug">
|
||||
<!ENTITY % gnomeincludes SYSTEM "../includes.sgml"> %gnomeincludes;
|
||||
<!ENTITY % includes SYSTEM "../../includes.sgml"> %includes;
|
||||
|
|
@ -15,72 +15,76 @@
|
|||
|
||||
<h2>1. What to report?</h2>
|
||||
|
||||
<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 the contrary, the
|
||||
situation is 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>The rule of the thumb is: report as much information as you
|
||||
can. Even if there is some irrelevant information
|
||||
developers can easily filter it out. On the contrary, the
|
||||
situation is 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> 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>
|
||||
<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> Needless to say, that such a report
|
||||
is just a waste of your time, time of the appropriate developer,
|
||||
and network bandwidth. At a bare minimum the report should
|
||||
include the following information:</p>
|
||||
|
||||
<ul>
|
||||
<li><p>Exact version of the operating system (usually output of
|
||||
<tt>uname -a</tt>).</p></li>
|
||||
<li><p>List of all packages installed on your system.</p></li>
|
||||
<li><p>Your environment (output of <tt>/usr/bin/env</tt>).
|
||||
<li><p>If you are building from ports then approximate time when you was
|
||||
last time updating your ports tree.</p></li>
|
||||
<li><p>If you are building from ports then the approximate time
|
||||
when you last updated 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 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 already knows all
|
||||
about the problem, but is just too lazy to fix it.</p></li>
|
||||
unsuccessful build in the case when the build of the port is
|
||||
broken, stack trace in the case of a core dump, clear and
|
||||
detailed description of the problem when the application does
|
||||
something unexpected, etc. Try to put yourself into the
|
||||
developer's shoes and in each particular case evaluate what
|
||||
information would be necessary for them to locate the source of
|
||||
the problem. Do not just assume that they already know all
|
||||
about the problem, but are just too lazy to fix it.</p></li>
|
||||
</ul>
|
||||
|
||||
<p>If you have a solution or a workaround for the problem then include
|
||||
it into your report as well, even if you are not quite sure that this
|
||||
is a correct fix, if it is not it could give developer idea about
|
||||
what to look at and save him some time.</p>
|
||||
it into your report as well, even if you are not quite sure that
|
||||
this is a correct fix. If it is not it could still give the
|
||||
developer an idea about what to look at; and save them some time.
|
||||
</p>
|
||||
|
||||
<h2>2. Where to report?</h2>
|
||||
|
||||
<p>There are several ways to report a bug in GNOME running on a FreeBSD
|
||||
system: you could send report to the
|
||||
system: you could send a report to the
|
||||
<a href="mailto:&email;@FreeBSD.org">freebsd-gnome mailing
|
||||
list</a>, file a problem report in
|
||||
list</a>, file a problem report in the
|
||||
<a href="http://www.freebsd.org/support.html#gnats">FreeBSD bug
|
||||
reporting system</a>, send your report to the particular GNOME
|
||||
developers via their
|
||||
<a href="http://bugzilla.gnome.org/">bug tracking system</a> or any
|
||||
combination of those.<p>
|
||||
<a href="http://bugzilla.gnome.org/">bug tracking system</a>, or
|
||||
any combination of those.<p>
|
||||
|
||||
<p>It is impossible to define guidelines that will clearly tell you where
|
||||
to report in each particular case - you have to use your own common
|
||||
sense, however some rules follow:</p>
|
||||
<p>It is impossible to define guidelines that will clearly tell you
|
||||
where to report in each particular case - you have to use your own
|
||||
common sense, however some rules follow:</p>
|
||||
|
||||
<ul>
|
||||
<li><p>If the problem is FreeBSD-specific and transient (e.g. checksum
|
||||
mismatch, patch failure, syntax error in port's Makefile etc.) then
|
||||
report to the freebsd-gnome mailing list.</p></li>
|
||||
<li><p>If the problem is clearly not FreeBSD-specific and you have no
|
||||
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 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
|
||||
the need to wait for a next vendor's release.</p></li>
|
||||
<li><p>If the problem is FreeBSD-specific and transient (e.g.
|
||||
checksum mismatch, patch failure, syntax error in port's Makefile
|
||||
etc.) then report to the <a href="mailto:&email;@FreeBSD.org">
|
||||
freebsd-gnome mailing list</a>.</p></li>
|
||||
<li><p>If the problem is clearly not FreeBSD-specific and you have
|
||||
no 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 problem is not FreeBSD-specific, but quite serious
|
||||
and you have a fix available then report both to FreeBSD and
|
||||
author's 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 the need to wait for the vendor's next
|
||||
release.</p></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
|
|
|
|||
Loading…
Reference in a new issue