If you want to submit bug or problem report, fill in the submit form. After you send the submit button, your message will be queued to GNATS. GNATS usually process the queue each several minutes. After your message is processed, you will be notified by e-mail (so it is important to fill in right e-mail address). If you will not have received the notification within a day after successful submission, you should probably contact the GNATS administrator on this site. You can find his address in the foot of the index page.
The form contains the fields described in the next section. See also the section with useful hints about submitting problem reports.
Depending on local gnats2w configuration, not all of the described fields must be present in your form.
The name of the product, component or concept where the problem lies.
Just select one. [L] describes the categories.
Release or version number of the product, component or concept. Examples: 0.6, 19990225.
If you check in this field, the problem will be considered as confidential. What it means exactly is depending on local gnats2w configuration. Usually confidential problems reports can be viewed and edited only by people with special access rights to the bug tracking system.
One-line summary of the problem. The bug tracking system copies this information to the subjects of mails sent by the system and this identification is also used in various places of the WWW interface. Example: Incorrect date of closing.
The class of a problem can usually be one of the following (the list may vary depending on a particular bug database):
Select one.
The severity of the problem. Possible values include:
Select one.
How soon the originator requires a solution. Possible values include:
Select one.
Your name. It is not necessary to fill in this field if you do not want.
If you want to ever receive any answer or notification about your problem, it is a good idea to fill in your correct e-mail address here.
Precise description of the problem. Proper information in this field is crucial for diagnosing the problem, so try to fill in it carefully, please.
See also some useful hints about reporting problems.
Example code, input, or activities to reproduce the problem. The support organization uses example code both to reproduce the problem and to test whether the problem is fixed. Include all preconditions, inputs, outputs, conditions after the problem, and symptoms. Any additional important information should be included. Include all the details that would be necessary for someone else to recreate the problem reported, however obvious. Sometimes seemingly arbitrary or obvious information can point the way toward a solution.
See also some useful hints about reporting problems.
A description of a solution to the problem, or a patch which solves the problem. (This field is most often filled in at the Support Site; we provide it to the submitter in case she has solved the problem.)
Description of the environment where the problem occurred: machine architecture, operating system, host and target types, libraries, pathnames, etc.
There is no orthodox standard for submitting effective bug reports, though you might do well to consult the section on submitting bugs for GNU gcc in the GCC manual by Richard Stallman. This section contains instructions on what kinds of information to include and what kinds of mistakes to avoid.
In general, common sense (assuming such an animal exists) dictates the kind of information that would be most helpful in tracking down and resolving problems in software.