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

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

• Finally, the FreeBSD PR database. Unless your problem is recent or obscure, there is a fair chance it has already been reported.

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.