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 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:
+Always report as much information as you can. Too much + information is always preferable to too little information. + Superfluous information can be filtered out; developers like + to play guessing games with code, not with bug reports.
+ +A good bug report should at least include the following + information:
Exact version of the operating system (usually output of uname -a).
List of all packages installed on your system.
List of all packages installed on your system (output of + pkg_info).
Your environment (output of /usr/bin/env). -
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 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 are building from ports, note approximately how + long it has been since you last updated your ports tree. If + it has been more than a day, or if you haven't run + portupgrade -a, don't bother sending a bug report + until you've run cvsup and portupgrade.
Information specific for each type of breakage:
+In addition, try to answer the following questions:
- -Also, be prepared to answer additional questions. Often times, - developers cannot solve or even diagnose a problem right off the - bat. So please be understanding when asked to provide more - information.
- -If you have a solution or a workaround for the problem then include +
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 still give the - developer an idea about what to look at; and save them some time. + it is a proper fix. Even if the fix isn't quite right, it could still + point others in the right direction.
-Before reporting a bug, or even sending an email to the list, - search - through the FreeBSD GNOME mailing list archives to see if this - has already been reported. Most of the problems reported on - the mailing list are repeats, and by searching you can find - your solution much faster. -
- -Once you are sure this is a new problem, there are several ways +
Once you are sure it is a new problem, there are several ways to report a bug in GNOME running on FreeBSD: you could send a report to the freebsd-gnome mailing @@ -99,25 +75,24 @@ 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 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.
If the problem is FreeBSD-specific (usually, this means + a problem with building or upgrading), then report to the + freebsd-gnome mailing + list, or file a bug report through the + FreeBSD bug + reporting system.
If the problem has to do with an application's + behaviour, report the problem directly to the applicaiton's + developers through the GNOME project's + bug tracking system
If the problem is quite serious, not necessarily + FreeBSD-specific, and you have a fix available, report + it to both the FreeBSD GNOME team and the application's + developers. This way, the application's developers can apply + the patch to CVS, and the FreeBSD GNOME team can apply the + patch immediately to the ports tree without needing to wait + for the next release.
Other release-specific issues can be found in the + general FAQ and the + GNOME &gnomever; upgrade FAQ.
You should follow the - - instructions for updating to GNOME &gnomever;. This may - still produce errors, however. You may have to re-run - pkgdb -F after each step. If you continue to - encounter errors after following the upgrade instructions, - log the entire upgrade procedure (you can use the -l - option to portupgrade to accomplish this). - Compress and send the log to - &email;@FreeBSD.org. -
+It certainly is tricky, and you are not expected to + accomplish it by hand. Read the + upgrade FAQ for detailed + information.
Test existing ports, and - report bugs.
Regularly install GNOME from packages, and report any problems with the install or the functionality.
Subscribe to the freebsd-gnome mailing list, and help answer users' questions.
-Take patches and feedback from GNOME-related FreeBSD PRs - back to GNOME authors so that the patches can be integrated - into the next release of the application.
Proofread the FreeBSD GNOME project pages, and offer feedback and updates.
If you are brave, please help fix the lang/mono port! +
Send any feedback to
diff --git a/en/gnome/index.xsl b/en/gnome/index.xsl
index 6910213908..018abbd93f 100644
--- a/en/gnome/index.xsl
+++ b/en/gnome/index.xsl
@@ -1,4 +1,4 @@
-
+
For more information about what GNOME is and isn't, check out
+ the GNOME Project's
+ About GNOME page. GNOME for FreeBSD is currently supported on 4.9, 5.2,
State of the port