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

Reporting a bug

+ + + + +
-

1. What to report?

+

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.

+

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:

+

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

  • 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, even if it is not it could give developer idea about - what to look at and save him some time.

+

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?

+

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 - combination of those.

+

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 + 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 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 - 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 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 + other users of FreeBSD will be able to benefit from your fix, without + the need to wait for a next vendor's release.

    • +
+
&footer;