(→Profile) |
(→Flag) |
||
| (9 intermediate revisions not shown) | |||
| Line 6: | Line 6: | ||
==Target Build== | ==Target Build== | ||
| - | The main purpose of this field is for | + | The main purpose of this field is for developers to predict on which build the bug can be fixed. |
When developers get a bug and acknowledge the issue, they are expected to change the status from NEW to ASSIGNED, and set a Target Build to forecast when the issue can be fixed. | When developers get a bug and acknowledge the issue, they are expected to change the status from NEW to ASSIGNED, and set a Target Build to forecast when the issue can be fixed. | ||
| Line 41: | Line 41: | ||
===Platform=== | ===Platform=== | ||
| - | Platform field indicates the hardware platform against which the bug is detected, like ExoPC, Moorsetown, N900, | + | Platform field indicates the hardware platform against which the bug is detected, like ExoPC, Moorsetown, N900, Oaktrail, etc. |
==Keywords== | ==Keywords== | ||
| Line 47: | Line 47: | ||
[https://bugs.meego.com/describekeywords.cgi Keywords] can be added to reports to quickly find issues of the same keyword category across various products and components. | [https://bugs.meego.com/describekeywords.cgi Keywords] can be added to reports to quickly find issues of the same keyword category across various products and components. | ||
| - | + | The adding and deleting of keywords will follow the [http://wiki.meego.com/Quality/BugzillaRequestProcess common process of changes in Bugzilla]<br> | |
| - | + | ||
| - | + | ||
==See Also== | ==See Also== | ||
| Line 58: | Line 56: | ||
==PM Comment== | ==PM Comment== | ||
| - | This field is for MeeGo PM team to record the TODOs,AR(Action Required),etc for MeeGo release key issues.<br> By using this field, PM comments can be | + | This field is for MeeGo PM team to record the TODOs, AR (Action Required), etc for MeeGo release key issues.<br> By using this field, PM comments can be easily found. And meanwhile, PM is able to export the data in custom field easily for further using. |
| - | * [https://bugs.meego.com/show_bug.cgi?id=16304 | + | * See [https://bugs.meego.com/show_bug.cgi?id=16304 this report] for the request for addition of a custom PM comment field. |
==Triaged By== | ==Triaged By== | ||
| - | "Triaged By" is used to track who | + | "Triaged By" is used to track who in-depth triaged a bug report. This field is intended to be used by system debug engineers. |
| - | * Please | + | * Please refer to [http://wiki.meego.com/Quality/SysDebug SysDebug] for more information on usage of this field. |
==Flag== | ==Flag== | ||
| - | We use these customized flags to manage release blocker bugs . | + | We use these customized flags to manage release blocker bugs. |
| - | * '''MeeGo_Update_Release_Blocker''' | + | * '''MeeGo_Update_Release_Blocker'''. |
| - | * '''MeeGo_Release_Blocker''' | + | * '''MeeGo_Release_Blocker'''. |
| - | * '''MeeGo_N900DE_Release_Blocker'''. | + | * '''MeeGo_N900DE_Release_Blocker'''. |
| - | + | * '''MeeGo_Tablet_Change_Control_List'''. | |
| - | <br>MeeGo release version and these blocker | + | |
| - | * [https://bugs.meego.com/show_bug.cgi?id=9533 | + | Any users can propose blocker bugs for a specific release, and users in a priviliged groups, like Program Managers, approve/reject these blockers. |
| + | |||
| + | '''TODO:''' ''(This process needs documentation)'' --[[User:Andre|Andre]] 10:14, 13 June 2011 (UTC). | ||
| + | |||
| + | <br>MeeGo release version and these blocker flags are used together to identify blocker issues in each releases uniquely. | ||
| + | * See [https://bugs.meego.com/show_bug.cgi?id=9533 this report] for the request for addition of a MeeGo_Update_Release_Blocker field. | ||
==Other reference pages== | ==Other reference pages== | ||
Contents |
MeeGo Release field defines in which MeeGo version a bug has been found. Version names are defined according to the MeeGo release plan. If a bug was reported already for an older MeeGo version make sure to handle this bug as described here.
The main purpose of this field is for developers to predict on which build the bug can be fixed.
When developers get a bug and acknowledge the issue, they are expected to change the status from NEW to ASSIGNED, and set a Target Build to forecast when the issue can be fixed.
Priority field describes the importance and order in which a bug should be fixed. It helps developers to prioritize their work. By default the priority is set as "Undecided" when reporting a new bug. A bug triage team sets the initial priority for the bug, which might be changed. Priorities range from High (most important) to Low (least important).
The "Severity" field describes the impact of an issue. The options include:
The type of device (like Netbook, Nettop, Notebook, Handset, Automotive, TV) the issue has been identified in. For bugs which apply to all UX (like bugs for Middleware/Core components), then "Common" should be selected.
The architecture (like IA, ARM) the issue has been identified in. For example N900 Base OS layer bugs are ARM, most Netbooks are IA. For bugs which apply for multiple architectures, like bugs for middleware or applications, there is "All".
Platform field indicates the hardware platform against which the bug is detected, like ExoPC, Moorsetown, N900, Oaktrail, etc.
Keywords can be added to reports to quickly find issues of the same keyword category across various products and components.
The adding and deleting of keywords will follow the common process of changes in Bugzilla
This allows you to refer to bugs in other installations. You can enter a URL to a bug in the "Add Bug URLs" field to note that that bug is related to this one. You can enter multiple URLs at once by separating them with a comma.
You should normally use this field to refer to bugs in other installations. For bugs in this installation, it is better to use the Depends On and Blocks fields.
This field is for MeeGo PM team to record the TODOs, AR (Action Required), etc for MeeGo release key issues.
By using this field, PM comments can be easily found. And meanwhile, PM is able to export the data in custom field easily for further using.
"Triaged By" is used to track who in-depth triaged a bug report. This field is intended to be used by system debug engineers.
We use these customized flags to manage release blocker bugs.
Any users can propose blocker bugs for a specific release, and users in a priviliged groups, like Program Managers, approve/reject these blockers.
TODO: (This process needs documentation) --Andre 10:14, 13 June 2011 (UTC).
MeeGo release version and these blocker flags are used together to identify blocker issues in each releases uniquely.