Revision as of 09:06, 25 June 2010

Create account

The http://bugs.meego.com authentication system is integrated with the http://meego.com authentication system, so the same account is used both for meego.com and bugzilla.meego.com. Click the link "New Account" from the http://bugs.meego.com home page to open the meego.com registration page. To register a new account, you must confirm your account by following the link you received in email and changing your password on meego.com, before attempting to log into bugzilla.

Bugzilla Field Definition

Version

Version field describes bugs found in which version. Currently 2 version names are defined according to MeeGo release plan: 1.0 and 1.1.

Target Milestone

When bugs are in OPEN or RESOLVED status, it's used by bug submitter to propose which milestone this bug is expected to be fixed.

• --- Undecided
• 1.0 Propose bug is expected to be fixed in 1.0
• 1.1 Propose bug is expected to be fixed in 1.1

Severity

The "Severity" field describes the impact of a bug, and the options include:

• Critical: crashes, other components are affected
• Major: major loss of own function
• Normal: regular issue, some loss of functionality under specific circumstances
• Minor: minor loss of function, or other problem, where an easy workaround is present
• Enhancement: request for enhancement

Priority

Priority field describes the importance and order in which a bug should be fixed. It helps developers to prioritize their work. The priority got to be set as "Undecided" when reporting a new bug. The bug reporter could propose a priority in comment. Dedicate bug triage team should set initial priority for the bug while processing it as early as possible. Final priority setting would be decided by bug triage process. Priorities range from High (most important) to Low (least important).

• High: Bug fixing is on-going, or is planned within 2 weeks, no later than the up-coming milestone. Reproducible crash issues, major function loss, issues greatly impact user experience or issues which block other key features to work would fall in to this category.
• Medium: Bug fixing is planned before project release, but can't start before HIGH priority items are cleaned up.
• Low: Bug fixing is not planned for the up-coming project release. Non POR feature request, hard to reproduce, or non-MeeGo environment bugs will fall into this category.

Architecture

For architecture specific bug, pls. select the architecture (IA, ARM) which you identify the bug in. For example, the architecture for N900 base OS layer bugs should be set to ARM.

For bugs which apply for multiple architectures, for example, some bugs for middleware or applications, pls. select the "All" in architecture.

Hardware

For vertical specific bug, please select the vertical (Netbook, Nettop, Handset, Automotive and Media Phone) which you identify the bug in.

For bugs which apply for multiple verticals (some bugs for middleware/core components for example), pls. select "All" in Hardware.

Bug Life Cycle

Bug Reporting/Follow-up Guideline

1. Each bug report is for only one issue. If you find several issues in one test, please separate them into several bugs.

2. Write a precise summary (bug title). A good summary should be straightforward and precise, to clearly identify the issue.

3. List the exact steps to reproduce the bug (bash commands, results after executing the commands etc, instead of only paraphrasing). For example, instead of paraphrasing commands by saying:

     "suspend the system or put system to S3"

we prefer to see the following exact commands as steps to reproduce the bug:

     echo mem >/sys/power/state

4. Reproducibility. For bugs which are not 100% reproducible, please provide the steps to reproduce the bug, along with an estimate of the probability of reproduction.

5. Impact to system or user. Provide a description of the impact to the system or user.

6. DO NOT reopen if same defect found again after more than 2 weeks. New bug report with “REG” keyword is mandatory.

7. NEEDINFO bugs should be assigned back to original bug status after additional data provided to the bug

8. For "target Milestone", when bugs are in OPEN or RESOLVED status, it means to propose bug fix in particular milestone; When verifying bugs, set correct milestone where the bug is fixed.