Orca Bugzilla Philosophy

The Orca team uses Bugzilla to track defects in Orca, defects in other components, and feature requests. As such an Orca "bug" in the Bugzilla is not always a defect and there can be redundancies.

"Tracking" ([blocked]) Bugs

We often file another bug against a component in GNOME and put a separate "tracking" bug in the Orca component. Bugzilla supports this and it is a useful feature. This gives us a simple reminder, for example, about what infrastructure bugs we need to track. It also gives the Orca community one stop shopping to help determine the set of known issues when it comes to accessing the overall desktop via Orca.

When we have a component outside GNOME that has a bug (e.g., Firefox, Thunderbird, Open Office, etc.), we'll also file a "tracking" bug in Orca and provide a URL to the other component's bug database. We also try to make sure to provide a link from the other component's bug database back to the Orca bug. Again, very useful for tracking, and also helpful to us because it helps direct users to the appropriate place to put pressure for getting things fixed.

For "tracking" bugs, we've adopted the convention of prefixing the bug summary with [blocked] (current list of blocked bugs). These typically account for a large number of all the bugs in the Orca database.

Bug Summary Conventions

We've also adopted a few other bug summary conventions. At any time, a bug might be prefixed with the following strings (each is optional):

[<name>][testing required, pending,verified,blocked][requirement] <summary of bug>

• <name> represents the name of a team member who needs to comment on the bug: mike, will, joanie, jon, eitan, etc. If there's more than one person who needs to comment, keep them in separate [] blocks to make searching easier. For example: [will][mike]. Please use all lower case when typing the names.

• testing required: means that a patch has been attached to the bug but will not be committed until others have confirmed its validity

• pending: means the changes for the bug has been checked in, and we're waiting for testing to confirm it's fixed

• verified: means testing has verified the bug is fixed and it is ready to close

• blocked: means a bug in another component is blocking the progress of this bug -- the bug report should contain a pointer to the other bug

• requirement: means this is a known requirement from our specification

For example, you might see a bug summary that looks like the following:

[will][mike][blocked][requirement] Find a cure for cancer

From time to time, we'll sit down as a team and enter a flurry of feature requests (RFEs) based upon new ideas and suggestions from users (current list of RFEs). These spikes typically occur towards the end every GNOME release cycle as we begin thinking about the next cycle.

Typical Bug Life Cycle

The typical life cycle for a bug is this:

1. Upon identification of a bug or enhancement request, one enters a new bug in the Orca bug database. All discussion regarding a bug should take place in the bug report. If discussions happen on IRC or in e-mail, the summary of those discussions should be captured in a comment to the bug. It helps a lot for future reference.
2. When a test case is developed, it is typically added to the bug as an attachment.
3. When a patch is created, it is added as an attachment.
4. If you're at all unsure of the patch, don't check it in, but instead ask for comments. If you need a comment from a specific person, prefix the bug summary with the person's name (e.g., "[will]"). If you just want others to test the patch, prefix the summary with "[testing required]"
5. When you're relatively sure of the patch, check it in. If you want Willie to review it, he will and he will mark the bug as "accepted-commit-now".
6. When you check the patch in, prefix the bug summary with "[pending]", and mark the patch as "committed". This is a flag that it needs to be tested.
7. Once someone has tested the bug, they will prefix the summary with "[verified]". This means you can close the bug as "FIXED".
8. When you close the bug as "FIXED", remember to mark the target milestone for where the bug will appear.

Meta Bugs

We also keep a few "meta tracking" bugs (metabugs). These bugs list the various other "tracking" bugs we have in the Orca database as a means to get an overall idea of how we are progressing on the various components.

For example, we have a bug for general Firefox problems, a bug for general Thunderbird problems, a bug for general Open Office problems, and a bug for general Java platform problems, and so on. Click here for a complete list of the metabugs.

You can also see a list of prioritized bugs on the following pages, though these tend to be out of date since the overhead in maintaining them is high:

• Prioritized Mozilla Bugs

• Prioritized Open Office Bugs

• Prioritized Acroread Bugs

This system works very well for our day to day and long term work for Orca. It also helps us communicate very well with the community. It may wreak havoc, however, on systems that perturb the counts in the bug database for other purposes.

As a result, of all the bugs in the Orca bug database, you'll find that only a small percentage are 'real' bugs on Orca itself.

Quick Searches

Verified and ready to close (thanks!)

Sorted by priority, severity, and age (ID): All, Unblocked, Blocked

Sorted by target milestone, priority, severity, and age (ID): All, Unblocked, Blocked

Sorted by individual:

• Unassigned

• Joanie: assigned (unblocked), waiting for comment

• Jon: assigned (unblocked), waiting for comment

• Mike: assigned, waiting for comment, testing required, pending

• Eitan: assigned (unblocked), waiting for comment

• Willie: assigned (unblocked), waiting for comment

"THE" list: sorted by target milestone, priority, severity, and age (ID)

"THE" list, but without blocked bugs