Revision as of 08:46, 8 April 2011

Bug Life Cycle

1. The reporter submits the bug for a specific component, then the bug is automatically assigned to the default owner for each component, showing in field "Assign To". The status is always NEW and priority is Undecided.
2. Bug triage team will follow the responsibilities defined in bug triage process to process bugs: ensure bug component is correctly set, enough information has been collected, bug priority is set etc.
3. The component owner should follow up when getting a new bug notification:
   • If the owner accepts the bug and assigns to himself/herself, he/she changes the status as ASSIGNED.
   • The owner may think that it's a wontfix bug. Bug owner should change the status to RESOLVED with resolution INVALID/WONTFIX/WORKSFORME with proper comments.
   • If the owner thinks that it is a bug of the other component, he/she needs to add a justification comment and move the bug to the proper component.
   • If the owner disposes the bug to other individual, then the new owner follow the same process.
   • If the owner thinks that the bug information is incomplete, he/she must change "status" as NEEDINFO to ask more info from bug reporter.
   • Once the reporter has a given more info, He/she sets NEEDINFO' back to NEW or ASSIGNED if it was already.
   • The owner does bug analysis and finds this bug comes from upstream. Owner can post a new bug in upstream bugzilla (or ask QA help to do this) and change status to WAITING FOR UPSTREAM. Be sure to add the upstream bugzilla link in MeeGo bugzilla comment area. When upstream bug is fixed, firstly, integrate the bug fix in distribution image, then mark status to be RELEASED - FIXED.
4. The owner (bug assignee) fixes the bug and changes the bug status to RESOLVED - FIXED. Assignee should add comments to explain the resolution and provide necessary infomation for distro engineer to get the fix and integrate it into distribution. It's a good practice to link the commit messages as well as the package(s) and their version.
5. Then distro engineer needs to integrate the fix into distribution and change the status to RELEASED - FIXED. It's a good practice to specifiy in which release the fix is found, a link to the downloadable image is even better to allow proper bug verification.
6. QA or Bug Submitter verifies bug fixing with the "how to re-produce" instructions in the original bug report when the bug is marked as "RELEASED - FIXED".
   • Bug is fixed: QA or reporter should change the bug status to VERIFIED and add a comment telling which image (e.g. netbook-200901221904) the bug has been fixed in. Don't need to mark it as "CLOSED".
   • Bug is not fixed: QA or bug submitter should change the bug status to REOPENED and add a comment telling which image you are using and the bug is still there.

Bug Report Handling/Follow-up Guideline

For reporting a bug, see here.

• 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.
• 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.
• 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.

MeeGo update bug fix acceptance criteria

Generally, the approved update release bugs must be fixed and verified in MeeGo Trunk firstly.

1. With Bugzilla, an approved release update (eg 1.1) bug must have a MeeGo bug entry in the latest release (eg 1.2) so QA can verify the latest (eg 1.2) Trunk build has the same bug fix on a target vertical platform.

2. With Bugzilla, an approved release update (eg 1.1) bug should have a bug in the latest release (eg 1.2) as a dependency (or blocker bug) to ensure that the associated bug in the latest release is verified first.

3. Update release engineer should _not_ accept development patch submission for update release unless QA verified in Trunk build and mark the Bugzilla entry accordingly.

Of course, there are some exceptions that don't apply this guideline especially for those bugs in old releases are not applicable to latest release. For example:

1. Bug fixes in old releases' components where the latest release is using a different version;

2. Components used in old releases that are no longer used in trunk;

3. Security fixes that don't apply to the version in trunk, etc.

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!!").

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.

See Also

• Fields in a bug report
• MeeGo Bug Triage
• How to report bugs