Views
Quality/Bug Life Cycle and Handling
From MeeGo wiki
< Quality(Difference between revisions)
m (→Bug Life Cycle) |
|||
| (7 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
| - | + | __TOC__ | |
| + | |||
[[file:Bug-life-cycle-meego.PNG]] | [[file:Bug-life-cycle-meego.PNG]] | ||
# 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'''. | # 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'''. | ||
| Line 5: | Line 6: | ||
# The component owner should follow up when getting a new bug notification: | # 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'''. | #* 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. | + | #* 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 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 disposes the bug to other individual, then the new owner follow the same process. | ||
| Line 13: | Line 14: | ||
# 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. | # 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. | ||
# 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. | # 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. | ||
| - | # '''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'''. | + | # '''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 is | + | #* 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 not fixed: | + | #* 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 = | + | == Bug Report Handling/Follow-up Guideline == |
For ''reporting'' a bug, see [[Quality/How_To_Report_Bugs|here]]. | For ''reporting'' a bug, see [[Quality/How_To_Report_Bugs|here]]. | ||
| - | * DO NOT reopen if same defect found again after more than 2 weeks. New bug report with | + | * '''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 | + | * '''NEEDINFO''' bugs can optionally be assigned back to original bug reporter, though we do not encourage this activity. |
| - | * For "Target Milestone", when reports are in OPEN or RESOLVED status, it | + | * '''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 = | + | == MeeGo update bug fix acceptance criteria == |
Generally, the approved update release bugs must be fixed and verified in MeeGo Trunk firstly. | Generally, the approved update release bugs must be fixed and verified in MeeGo Trunk firstly. | ||
| Line 42: | Line 47: | ||
3. Security fixes that don't apply to the version in trunk, etc. | 3. Security fixes that don't apply to the version in trunk, etc. | ||
| - | = Guidelines = | + | == 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 [https://bugs.meego.com Bugzilla]. | We like to have fun but we also like the communications to run smoothly. To that end here are some guidelines for participating in [https://bugs.meego.com Bugzilla]. | ||
| - | ==Do be patient with others== | + | ===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!!"). | 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== | + | ===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 [[Community communication|forums and mailing lists]] for that. | * 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 [[Community communication|forums and mailing lists]] for that. | ||
* Avoid quoting complete previous comments by stripping unneeded lines. | * Avoid quoting complete previous comments by stripping unneeded lines. | ||
* Avoid answering above the quoted text. | * Avoid answering above the quoted text. | ||
| - | ==The admins Rule== | + | ===The admins Rule=== |
Ultimately, the admins reserve the right to block your account. See our [[Community guidelines|process for dealing with violations]] for more details. | Ultimately, the admins reserve the right to block your account. See our [[Community guidelines|process for dealing with violations]] for more details. | ||
| - | = How to get involved = | + | == How to get involved == |
As a non-coder you can get involved by [[Quality/How_To_Report_Bugs|reporting bugs]] and [[Quality/Bugtriage|triaging bug reports]]. | As a non-coder you can get involved by [[Quality/How_To_Report_Bugs|reporting bugs]] and [[Quality/Bugtriage|triaging bug reports]]. | ||
| - | =See Also= | + | ==See Also== |
* [[Quality/Bugzilla_Fields|Fields in a bug report]] | * [[Quality/Bugzilla_Fields|Fields in a bug report]] | ||
* [[Quality/Bugtriage|MeeGo Bug Triage]] | * [[Quality/Bugtriage|MeeGo Bug Triage]] | ||
* [[Quality/How_To_Report_Bugs|How to report bugs]] | * [[Quality/How_To_Report_Bugs|How to report bugs]] | ||
| + | |||
| + | [[Category:QA]] | ||
Latest revision as of 02:20, 26 April 2011
Contents |
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.