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