3. Preparations

A good rule to follow is to always do a background search before submitting a problem report. Maybe your problem has already been reported; maybe it is being discussed on the mailing lists, or recently was; it may even already be fixed in a newer version than what you are running. You should therefore check all the obvious places before submitting your problem report. For FreeBSD, this means:

• The FreeBSD Frequently Asked Questions (FAQ) list. The FAQ attempts to provide answers for a wide range of questions, such as those concerning hardware compatibility, user applications, and kernel configuration.

• The mailing lists--if you are not subscribed, use the searchable archives on the FreeBSD web site. If your problem has not been discussed on the lists, you might try posting a message about it and waiting a few days to see if someone can spot something you have overlooked.

• Optionally, the entire web--use your favorite search engine to locate any references to your problem. You may even get hits from archived mailing lists or newsgroups you did not know of or had not thought to search through.

• Next, the searchable FreeBSD PR database (GNATS). Unless your problem is recent or obscure, there is a fair chance it has already been reported.

• Most importantly, you should attempt to see if existing documentation in the source base addresses your problem.

  For the base FreeBSD code, you should carefully study the contents of the /usr/src/UPDATING file on your system or its latest version at http://www.FreeBSD.org/cgi/cvsweb.cgi/src/UPDATING. (This is vital information if you are upgrading from one version to another--especially if you are upgrading to the FreeBSD-CURRENT branch).

  However, if the problem is in something that was installed as a part of the FreeBSD Ports Collection, you should refer to /usr/ports/UPDATING (for individual ports) or /usr/ports/CHANGES (for changes that affect the entire Ports Collection). http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/UPDATING and http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/CHANGES are also available via CVSweb.

Next, you need to make sure your problem report goes to the right people.

The first catch here is that if the problem is a bug in third-party software (a port or a package you have installed), you should report the bug to the original author, not to the FreeBSD Project. There are two exceptions to this rule: the first is if the bug does not occur on other platforms, in which case the problem may lie in how the software was ported to FreeBSD; the second is if the original author has already fixed the bug and released a patch or a new version of his software, and the FreeBSD port has not been updated yet.

The second catch is that FreeBSD's bug tracking system sorts problem reports according to the category the originator selected. Therefore, if you select the wrong category when you submit your problem report, there is a good chance that it will go unnoticed for a while, until someone re-categorizes it.