diff --git a/en/gnome/docs/bugging.sgml b/en/gnome/docs/bugging.sgml index a55923e695..566a8b131f 100644 --- a/en/gnome/docs/bugging.sgml +++ b/en/gnome/docs/bugging.sgml @@ -1,87 +1,91 @@ %includes; ]> &header;

1. What to report?

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 time guessing and/or asking originator of report to send more information.

There are plenty of examples of totally useless bug reports, something like "Hey, gnomefoo port is broken. I'm running FreeBSD-X.Y. Please fix." Nedless 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:

  • Exact version of the operating system (usually output of uname -a).

  • List of all packages installed on your system.

  • Your environment (output of /usr/bin/env).

  • If you are building from ports then approximate time when you was last time updating your ports tree.

  • 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 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 about the problem, but is just too lazy to fix it.

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.

2. Where to report?

There are several ways to report a bug in GNOME running on a FreeBSD - system: you could send report to the freebsd-gnome mailing list, file - a problem report in FreeBSD bug reporting system, send your report - to the particular GNOME developers via their bug tracking system or any + system: you could send report to the + freebsd-gnome mailing + list, file a problem report in + FreeBSD bug + reporting system, send your report to the particular GNOME + developers via their + bug tracking system or any combination of those.

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:

  • 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.

  • 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).

  • If the proble isn't a FreeBSD-specific, but quite serious and you have a fix available then report both to FreeBSD and authors' bug - tracking system, so that the appropriate port will be patched and + 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.
&footer;