From The Linux Foundation

What Is Bugzilla?

Bugzilla is a database for bugs. The LSB project uses this tool to let people report bugs, and assigns these bugs to the appropriate developers. Developers can use Bugzilla to keep a to-do list as well as to prioritize, schedule and track dependencies.

Not all 'bugs' are bugs. Some items in the database are known as Requests For Enhancement (RFE). An RFE is a bug whose severity field is set to 'enhancement'. People often say 'bug' when they mean 'item in Bugzilla', so RFEs often wind up being called bugs.

Enter the tasks you're planning to work on as enhancement requests and Bugzilla will help you track them and allow others to see what you plan to work on. If people can see your flight plan, they can avoid duplicating your work and can possibly help out or offer feedback.

Most significant work should have a bug. Bugs are the audit trail for work done towards a release, and the primary means of generating release notes and other information about what was changed/added. cvs logs exist as a backup, but are not as useful since a single conceptual change may be spread across many components and directories, and are harder to track unless there's a bugzilla entry to unify them.

Anatomy of an LSB Bug

Bugs and RFEs are composed of many fields. Some of them are described here.

Product

The LSB has a few shippable products, each of which has a category in the Bugzilla. There are also some categories that are not really products, such as Infrastructure or Website; nonetheless the top-level container in Bugzilla is the Product so these are also classified as Products. The LSB has a particular complication in that there's a lot of cross-pollination between Products: a problem may require a database fix, and affect the spec, tests, and build tools. There is no hard policy on whether this should be filed as one or multiple bugs. A guideline might be if a single fix is likely to take care of multiple products in one go, a single bug is okay, but affected products should be noted as instructions to verifiers. In this situation, the specification should probably be considered the "master" category. If large chunks of discrete work is required on different products, multiple cross-referenced bugs may be better. If you're not sure, file one (and note the issue) and leave it up to triage to decide the next step.

Component

Each Product is divided into categories, which may be portions of the shippable product, a generic container (often All), or something else. Try to pick the right Product and Component to most accurately categorize your bug.

Platform

If the bug is architecture-specific, use the Platform field to indicate this. This information should also be duplicated in the bug Description and perhaps the Summary - as a third-level field Platform may not always be looked at (often left out of custom views to keep things on one screen-width). In some cases a Component is split into two: -generic and -archspecific. If picking the latter, Platform must be used to fully categorize the bug. If it applies to multiple architectures, but not all, just pick one applicable value for Platform and list the rest in the bug text.

Keywords

This field is used to store various keywords. The LSB does not use this field intensively, but a few keywords are defined to make for easier searches: backport (bug against one release, backport candidate for the previous release), FHS (FHS bugs/enhancements), helpwanted (need someone else to pitch in on this bug, perhaps to test), ISO (issues specifically from the ISO ballot for DIS 23360), rollup (bugs which are specifically dependency tracker bugs - see next item). For specification bugs, it is also recommended to use a keyword to indicate that, as progressing the bug may cause the category to be changed. Release notes are generally written against bugs fixed for the specification, so to still find them after the category changes, use spec31 for the 3.1 release, spec40 for the 4.0 release, etc.

Dependency

If a bug can't be fixed until another bug is fixed, that's a dependency. For any bug, you can list the bugs it depends on and bugs that depend on it. Bugzilla can display a dependency graph which shows which the bugs it depends on and are dependent on it. The LSB project uses dependencies to track releases by using "rollup" bugs to make the release depend on all of the mustfix bugs for the product. Those bugs can't be marked Resolved-Fixed until the dependencies are Resolved-Fixed.

Attachment

Add attachments to a bug where it makes sense. Please submit patches as attachments to bugs rather than inline in the bug or using email. Screenshots, error logs, and other descriptive information can also be attached, especially if pasting the text inline would make it harder to read than using an attachment (e.g. line wrapping can make inline pastings unreadable). Note you need to create the bug first, then as a separate step add the attachment. Never simply attach a patched source file ... someone else may edit the offending file while this bug is being reviewed, and that makes it much harder for a reviewer to see what changed.

Life Cycle of an LSB Bug

Bugs submitted to the LSB Bugzilla by default go straight into the NEW state. Unless otherwise marked at submission time, it will get the default owner, which is the mailing list for the subproject that owns that product. This means it doesn't have a specific developer assigned to it yet. Bug triage will cause this to be assigned, or someone may simply take it. If the bug remains new and inactive for more than a week, Bugzilla nags the bug's owner with email until action is taken. Whenever a bug is reassigned or has its component changed, its status is set back to NEW. The NEW status means that the bug is newly added to a particular developer's plate, not that the bug is newly reported - this gives the developer a chance to either Accept the bug or disagree with the assignment by assigning it to someone else, possibly back to the category owner.

Whenever you change a field in a bug it's a good idea to add additional comments to explain what you are doing and why. Make a note whenever you do things like change the component, reassign the bug, create an attachment, add a dependency or add someone to the CC list. Whenever someone makes a change to the bug or adds a comment, the owner, reporter and the the CC are sent an email (unless they have switched it off) showing the changes to the bug report. The LSB Bugzilla is configured to require a comment for most changes.

There are two ways that a bug typically gets resolved:

• Simple bugs - you work on the offending source material, find the problem and fix it. Build and test the affected module. If you are convinced that this is the correct fix without further review, simply check in the changes in CVS and describe your changes in the bug while marking it RESOLVED-FIXED.
• More complex bugs - as before, work on the source code until you believe that you have addressed the problem. At that point, develop a patch (use diff -u or gendiff) and attach that to the bug (see "Attachments" above). Add any appropriate reviewers to the bug's "Cc list". Leave the bug Open (assigned to you) until others have had a chance to review your patch. Only commit the patched code to cvs and mark the bug RESOLVED-FIXED after this review has taken place. Note that other people may have updated the same source while the bug was in review, so always

  cvs update

  all the affected files and reapply the patch to them before commiting them to CVS.

For bugs which affect multiple categories, if someone else has to work on some other category, the bug should be reassigned after your piece is complete.

The LSB project has not used the bugzilla voting feature, if someone can suggest how that would be beneficial, we'll consider it.

When work on a bug is complete it's marked RESOLVED and given one of the following resolutions:

FIXED

A fix for this bug has been checked into the cvs tree and tested by the person marking it FIXED.

INVALID

The problem described is not a bug.

WONTFIX

The problem described is a bug which will never be fixed, or a problem report which is a "feature", not a bug.

DUPLICATE

The problem is a duplicate of an existing bug. Marking a bug duplicate requires the bug number of the duplicating bug and will add a comment with the bug number into the description field of the bug it is a duplicate of.

WORKSFORME

All attempts at reproducing this bug in the current build were futile. If more information appears later, please re-open the bug, but for now it's closed.

Next, someone will need look at resolved bugs and ensure the appropriate action has been taken. If they agree, the bug is marked VERIFIED. Bugs remain in this state until the product ships, at which time the bug is marked CLOSED. If they are not verifiable, they should come back to life by becoming REOPENED. Blocker bugs are not considered fully unblocked until they are verified. This means that rollup bugs cannot be marked RESOLVED-FIXED until the blockers are verified; and ollups must also be verified. As a matter of policy, someone other than the bug fixer or major contributors should verify fixed bugs. It's fine for the submitter to verify, subject to the aforementioned policy. Bugs are fixed when the change is committed, but are verified against the product, not the cvs tree: spec bugs should be checked against a generated spec, software bugs against snapshot or beta builds.

Be careful when changing the status of someone else's bugs. Instead of making the change yourself, you may wish to make a note of your proposed change as a comment and let the bug's owner review this and make the change themselves. For instance, if you think one bug is a duplicate of another, make a note of it in the 'Additional Comments' section.

---

[wiki:UsingLsbBugzilla/Comments User Comments] [[Include(UsingLsbBugzilla/Comments)]]