Views
Quality/How To Report Bugs
Contents |
Getting started
All you need is an account to be able to file and comment on reports. The http://bugs.meego.com authentication system is integrated with the http://meego.com authentication system, so the same account is used for both sites. To create a MeeGo account visit the registration page. Soon after you will receive an email with a link that must be visited to confirm your account creation. You will have to change your password on meego.com before attempting to log into Bugzilla.
Bugzilla Fields
MeeGo Release
MeeGo Release field defines in which MeeGo version a bug has been found. Version names are defined according to the MeeGo release plan.
Target Milestone
When bugs are in OPEN or RESOLVED status, it is used by the bug reporter 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
Importance
Priority
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. The bug reporter could propose a priority in a comment. A dedicated bug triage team should set the 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. Will re-evaluate the importance in next release.
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
- Trival:cosmetic problem like misspelled words or misaligned text
- Enhancement: request for enhancement
Platform
Hardware
Please select the UX (like Netbook, Nettop, Notebook, Handset, Automotive, TV) that you identified the bug in. For bugs which apply to all UX (like bugs for Middleware/Core components), please select "All".
Architecture
Please select the architecture (IA, ARM) that you identified the bug in. For example for N900 Base OS layer bugs this should be set to ARM. For bugs which apply for multiple architectures, like bugs for middleware or applications, please select "All".
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. This also helps avoiding duplicate reports.
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. Describe the current outcome and the expected outcome. Try to avoid writing "See screenshot" or "See attached file" but describe it briefly in words so it can be found when querying for existing bug reports (this helps avoiding duplicate reports).
5. Reproducibility. For bugs which are not 100% reproducible, please provide an estimate of the probability of reproduction.
6. Impact to system or user. Provide a description of the actual impact to the system or user.
7. DO NOT reopen if same defect found again after more than 2 weeks. New bug report with “[REG]” as a prefix in the summary is mandatory.
8. NEEDINFO bugs should be assigned back to original bug reporter and NEEDINFO status should be removed after requested missing data has been provided in the report. NEEDINFO status should only be used for requests against the original bug reporter.
9. For "Target Milestone", when reports are in OPEN or RESOLVED status, it means to propose the bug to get fixed for a particular release; When verifying bugs, set the correct milestone where the bug is fixed.
Guidelines
We like to have fun but we also like the communications to run smoothly. To that end here are some guidelines for participating in Bugzilla.
Do be patient with others
We have both techies and non-techies here and we both know we don't exactly speak the same language at all times. In case of missing information kindly tell reporters how to provide it, and/or point to https://bugs.meego.com/page.cgi?id=bug-writing.html in case of very vague reports (like "Can't send mail, plz help!!").
Do search before you file a bug
Try to avoid filing duplicates by taking a look whether your issue has already been filed before.
Keep it clean
- Don't start endless debates on topics not directly related to the scope of a specific bug report, for example release engineering or marketing. We have forums and mailing lists for that.
- Avoid quoting complete previous comments by stripping unneeded lines.
- Avoid answering above the quoted text.
The admins Rule
Ultimately, the admins reserve the right to block your account. See our process for dealing with violations for more details.
How to get involved
As a non-coder you can get involved by reporting bugs and triaging bug reports.