diff --git a/en/gnome/docs/bugging.sgml b/en/gnome/docs/bugging.sgml index c2f0e65abb..a129a26c98 100644 --- a/en/gnome/docs/bugging.sgml +++ b/en/gnome/docs/bugging.sgml @@ -1,91 +1,95 @@ - + %gnomeincludes; %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 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.

+

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.

-

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." 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:

+

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." 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:

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

    • +

  • If you are building from ports then the approximate time + when you last updated 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 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.

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

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.

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

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 + system: you could send a report to the freebsd-gnome mailing - list, file a problem report in + list, file a problem report in the FreeBSD bug reporting system, send your report to the particular GNOME developers via their - bug tracking system or any - combination of those.

+ 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:

+

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

    • +

  • 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 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.
&footer;