From The Neuros Technology Wiki
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.
Tables and Views
(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.
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.
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)
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.
|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|
|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|
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.
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)