36614bb08c
- move KDE into its own section: Related Projects; - add dummy (so far) entry for a link to a GNOME on GNU/Darwin page.
91 lines
4.2 KiB
Text
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 contrary, 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:freebsd-gnome@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>
|