Quality/Bug Life Cycle and Handling

Latest revision as of 02:20, 26 April 2011

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. You must include a comment if using any of these 3 resolutions.
   • 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 Contact 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 reporter is responsible for change bug status to VERIFIED; If bug reporter doesn't come back to verify bugs in 2 weeks after bugs have been marked RELEASED - FIXED, QA contact will help to retest and verify the bugs with comments "verified on behalf of reporter" added. If QA contact has difficulty to follow up the original bug report, and fails to get clarification from reporter, QA contact will set assign keyword "verification pending" to the bugs.
   • Bug is fixed: Bug status should be changed to VERIFIED and a comment should be added telling people which image (e.g. netbook-200901221904) the bug has been fixed in. Don't need to mark it as CLOSED (this is performed later by the QA team).
   • Bug is not fixed: bug status should be changed 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 can optionally be assigned back to original bug reporter, though we do not encourage this activity.
• NEEDINFO status should be removed after requested missing data has been provided in the report. The reporter must set the bug back to NEW or ASSIGNED status if it was already.
• 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 indicates a proposal to get the fixed for a particular release; When verifying bugs, the target milestone indicates in which particular release the bug is fixed.
• If there is a bug which was logged in the earlier releases, and in the latest release it is not reproducible, reporter or QA should leave a comment to indicate that the issue is not reproducible, specify the image information, device information and package information, and ask bug owner if he/she agrees the bug has been fixed. In good situation, bug owner will comment that bug so that we could handle the bug based on comments. If bug owner doesn’t respond, the bug would be retested a week later and if it’s still not reproducible, the bug could be “VERIFIED-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