Bugzilla OSD

From The Neuros Technology Wiki

Jump to: navigation, search

Neuros Technology | Products: LINK, OSD, Tablet | Developers


Bugzilla is the primary formal tool for communicating bug and enhancement priorities to the Neuros internal developers. It is also intended to be the tool that communicates bug prioritities and ownership to "outside" Neuros hackers. This little guide is intended to give some information on how it should be used and what to look for.


Target Milestone

Dates and summaries of target milestones can be found on the development schedule at open.neurostechnology.com in the development schedule(pdf)

Tables and Views

OSD Component Table

(NOTE: In all tables, you can click on the numbers in each cell for details about those bugs)

This table summarizes the bugs for all the various "components" for the OSD. These components are just classifications that make it easier to categorize the various bugs. You can find more information about what the components mean by looking at the OSD Component Descriptions.

Components/Votes Table

This table displays the number of votes for the various bugs within each component. Voting for bugs is a great way for any user to participate in the prioritization process. We give great weight to those bugs that are most popular, so please start voting and give us guidance on what you most want fixed. To vote on a bug, simply click the link that says "vote for this bug" when viewing the bug's details. The vote link is between the "depends on" and the "additional comments" box.

Bugs assigned to jborn

This table is where we need your input. Bugs that are assigned to jborn typically mean that they are looking for user feedback or more specific instructions. "menu is not intuitive" is not adequately specific for example for the internal team to fix. Bugzilla is an excellent place to input your suggestions/thoughts for how problems should be fixed. If the discussion is elsewhere or too long for bugzilla, you can link to discussions on the mailing list, forums, wiki, etc.

What's missing? There's a lot that's not yet in bugzilla and it's unlikely to get fixed or implemented before it makes it into bugzilla. Even hackers without the time to really participate in development can help a lot by inputing bugs into the system. Good sources for material can be found in the Bounties, an old OSD "roadmap" Doc (should really be deleted once input into Bugzilla), OSD Roadmap&History, and OSD Ideas.

Volunteers Needed Besides the obvious of populating, fixing and clarifying bugs, being the default assignee for a "component" is a very useful function. In order to effectively do this, you need to be able to monitor incoming bugs, make sure they belong in the component, that the explanations are adequately clear and that they are assigned to the right folks and categorized/prioritized correctly. If you'd like to be the default assignee on a component, please send an email to jborn at neurostechnology (dt. com)

NOTE: you'll have to signup to view the reports and bugs in bugzilla, but it only requires an email address. Bugzilla only sends email when you request it.

Neuros Development Process

(copied shamelessly from eclipse.org)

Priority Definitions

Priorities will determine or in which bugs will be worked on. This will be determined not just by severity, but also based on difficulty. ie, if somethign is very easy, it can get moved up to P1 even if not a release blocker.

Priority Definition
P1 Most immediate fixes, must be fixed before next release
P2 Should not release without this fix
P3 can release without, but will have to be careful who we sell to
P4 Ready for mainstream once fixed
P5 Nice to have

Severity Definitions

Severity Definition
Blocker Prevents basic functionality of device from working multiple functions, device is unusable without fix
Critical Prevents basic functionality of device, device is unusable for most users without fix
Major Prevents basic functionality of device, but workaround is possible (transcoding,etc)
Normal A problem making a function difficult to use but no special work around is required
Minor A problem not affecting the actual function, but the behavior is not natural
Trivial A problem not affecting the actual function, a typo would be an example

Bugzilla Process

The bugzilla Reporter (a.k.a. "Originator" or "Submitter"), when opening a defect, (can be anyone internal or from community)

1. Sets the severity level of the bugzilla (Severity = anything other than "enhancement").

2. Sets the the Version of device that the originator found the bug in.

3. The reporter does not adjust the Priority of the bug. For defects, the assignee chooses the Priority while the reporter chooses the Severity.

The bugzilla Reporter (a.k.a. "Originator" or "Submitter"), when opening an enhancement,

1. Sets the severity level of the bugzilla (Severity = "enhancement").

2. Sets the version that the reporter wants the feature done in.

3. Chooses the Priority of the bugzilla only if the bugzilla is for an enhancement. The reporter should state in the description what priority (P1/P2/P3) that this enhancement is for them, and the assignee sets the priority field to match. The assignee then negotiates with the reporter if they disagree with the priority of the enhancement.

Note that the priority level chosen by the reporter is a guideline only, and may or may not be changed by the internal team when it's time to schedule resources.


Bug is assigned to test team if verification is needed. Test team should do one of the following,

1 Bug verified and assigned to development team (eyu @ neuros.com.cn)

2 Bug unable to be verified, add comments to ask for further help from the original reporter.

3 If Bug has already been fixed, mark it fixed.

The bugzilla Assignee (a.k.a. "Owner" or "Committer"), when processing a bugzilla,

1. Chooses the priority level of defects.

2. Sets the target milestone. The target milestone reflects when the bug will be resolved.

If the assignee disagrees with the severity, the assignee negotiates with the reporter to adjust. Likewise, if the reporter disagrees with the priority or target milestone, the reporter will negotiate with the assignee to adjust. However, typically each will not directly change the others' settings.

Resolving Bugs

1. Developer gets assigned bug, fixes the bug and reassign it back to test team (kwang @ neuros.com.cn) with a simple comment explaining what was the cause of the problem.

2. Reporter and test team should verify that bug is fixed.

3. If reporter does not respond, or bug cannot be verified resolved by internal team, do not mark fixed. Just comment that cannot resolve due to issue.

4. Resolve LATER means that resolution depends on outside/external resources (like codec or silicon vendor)

5. Only the reporter or Mgao or JoeBorn Should close bugs after verification.

Personal tools