Reporting Bugs

Bugzilla for Lustre is an issue tracker as well as a bug tracker. It is a one-stop repository for:
 * Bugs
 * Enhancement requests
 * Patch submission
 * Patch review and dependency tracking

A bug-tracking system is less-error prone and superior to email in dozens of ways. For this reason we ask that all the above issues be handled exclusively through Bugzilla.

All of the important links described below are accessible from the Bugzilla main page or the toolbar at the bottom of each Bugzilla page.

Opening an Account
To use Bugzilla, you will need to open an account. On the Main page, click on "Open a new Bugzilla account". You will be asked to enter a valid email address. An email will be sent to you confirming the creation of your account.

Searching for Bugs
You can search for bugs in Bugzilla in two ways:


 * Enter the bug number or search on a keyword.
 * Search on a specific field or specify detailed or complex criteria. For more information about advanced searches see the Bugzilla User's Guide

Filing a Bug
Before opening a new bug report, do a quick search to avoid filing a duplicate bug.

To enter a new bug report, click on "New" or "Enter a new bug report". In the bug report form, fill in as many fields as you can. If your version of Lustre isn't listed, note that in the bug summary so that we can add it to the list. Please choose the correct component.

Include a descriptive summary. At a minimum, include the following:


 * Describe the problem that you're solving, the feature that you're adding, or the enhancement that you're requesting.
 * If you are reporting a bug, describe precisely the behavior that you're seeing and the behavior that you think is correct.
 * Provide a minimal a test case. For example, if 'tar' is crashing, try to narrow the issue down to a specific syscall. If you tried to narrow it down without success, tell us what you tried.
 * If you are submitting a patch, see Submitting Patches for a detailed procedure.

Priority Bugs
If you have a support contract for Lustre with Sun Microsystems, you will see a group membership tick box. Use this box to indicate that the bug is important for your project.

Accepting a Bug
When a bug is first filed, it is assigned to someone and its status is NEW. When that person accepts the bug its status changes to ACCEPTED, which signifies that he has acknowledged the bug and is working on it.

Resolving a Bug
When an issue is resolved and awaiting verification from the person who filed it, it is marked RESOLVED. From here, bugs are either re-opened and become REOPENED, are marked VERIFIED by the person who filed the bug, or are closed for good (when the product ships) and become CLOSED. CLOSED is rarely used.

A bug can be resolved for one of a number of reasons:


 * A fix for the issue was checked into the tree and tested (FIXED).
 * The bug report was too vague, described a non-bug, or is otherwise not useful (INVALID).
 * The issue is valid, but no action will be taken anytime soon (REMIND).
 * The issue is valid, but no action will ever be taken (WONTFIX).
 * The issue cannot be reproduced (WORKSFORME).
 * The issue is already filed elsewhere (DUPLICATE).

Advanced
A bug may have one or more keywords (http://bugzilla.lustre.org/describekeywords.cgi) associated with it, each of which has a special meaning. Consistent application of keywords allow for extremely useful searches.

By default, the reporter and assignee receive email when changes are made to a bug (you can change your email preferences at http://bugzilla.lustre.org/userprefs.cgi?tab=email). If you are interested in a bug, or want someone else to be involved, enter that person's account name in the Cc field. Any old email address will not work--this person must have a Bugzilla account to be on the Cc list.

Each bug has a list of bugs that it blocks and depends on. This list is updated automatically when you mark a bug as DUPLICATE, but you can also add your own dependency data by adding bugs to these fields. This feature is frequently used to create meta-bugs which are just placeholders to gather dependency data. For example, a "Lustre 1.0" bug would depend on all of the bugs that need to be fixed before Lustre 1.0 is released.

Private Groups
If you are the member of a private group, a checkbox will appear in the bug submission form and in the bug status. Check this box to make the bug visible only to members of the group (typically your organization and CFS staff). This is frequently used for bugs which contain sensitive information or have severe security implications.

Reports and Searches
Bugzilla can generate tables and charts (http://bugzilla.lustre.org/report.cgi) for various criteria. If you want to distribute a chart, please don't link to the chart page itself, because it will re-run the query for each hit. Instead, save the image somewhere, then link to the image directly. Our server thanks you.

Saved Searches
If you find yourself running the same searches frequently, you may wish to save them to the toolbar. It will give you one-click access to the search results that you use the most.

For example, clicking on this link will add a query named "All Bugs" that will show you all open Lustre bugs.

This link will add a query named "Important", which will show you all open bugs with a priority of P3 and higher.