Developers Guide to Bugzilla for Lustre

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.

Fixing a Bug

When attaching a patch for inspection, please follow Submitting Patches.

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.