doc/en/gnome/docs/bugging.sgml
2002-02-04 06:50:41 +00:00

91 lines
4.2 KiB
Text

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" [
<!ENTITY base CDATA "../..">
<!ENTITY date "$FreeBSD$">
<!ENTITY title "FreeBSD GNOME Project: Reporting a Bug">
<!ENTITY % gnomeincludes SYSTEM "../includes.sgml"> %gnomeincludes;
<!ENTITY % includes SYSTEM "../../includes.sgml"> %includes;
]>
<html>
&header;
<table border="0">
<tr>
<td>
<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>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>
<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>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>
</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>
<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
<a href="mailto:&email;@FreeBSD.org">freebsd-gnome mailing
list</a>, file a problem report in
<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>
<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>
</ul>
</td>
</tr>
</table>
&footer;
</body>
</html>