The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)
Bug Lifecycle
From Mer Wiki
(Difference between revisions)
m (typo) |
(Clarify "other", change misuse of CLOSED to RESOLVED and spell NEEDINFO correctly.) |
||
| Line 11: | Line 11: | ||
== Creation == | == Creation == | ||
# Select the appropriate Product. https://bugs.merproject.org/describecomponents.cgi should help. | # Select the appropriate Product. https://bugs.merproject.org/describecomponents.cgi should help. | ||
| − | # Now select the product specific Component. For Mer Core note that components are packages and "Other" or "package-groups". (COMMENT: This is going to get messy as packages are renamed, deleted and added. Should this use a Tag instead?) | + | # Now select the product specific Component. For Mer Core note that components are packages and "Other" or "package-groups". Use "Other" if you're not sure and Triage will fix it. (COMMENT: This is going to get messy as packages are renamed, deleted and added. Should this use a Tag instead?) |
# A bug is raised and automatically assigned to the "needs-triage" user. The status should be "UNCONFIRMED" | # A bug is raised and automatically assigned to the "needs-triage" user. The status should be "UNCONFIRMED" | ||
== Triage == | == Triage == | ||
# At the triage meeting the bug is reviewed and the priority/severity will be set and any obviously missing/wrong fields will be corrected. | # At the triage meeting the bug is reviewed and the priority/severity will be set and any obviously missing/wrong fields will be corrected. | ||
| − | # If the bug has too little information the status may be set to | + | # If the bug has too little information the status may be set to NEEDINFO. |
## Triage will periodically review NEEDINFO bugs that are not responded too | ## Triage will periodically review NEEDINFO bugs that are not responded too | ||
## The assignee is kept as "needs-triage" | ## The assignee is kept as "needs-triage" | ||
| − | ## Guideline for NEEDINFO is to close as INVALID after 4 weeks in | + | ## Guideline for NEEDINFO is to close as INVALID after 4 weeks in NEEDINFO state with no response from reporter. |
# If the bug is obviously invalid it may be RESOLVED/ appropriately. | # If the bug is obviously invalid it may be RESOLVED/ appropriately. | ||
# Otherwise the bug is set to NEW and assigned to the "not-taken" user. This indicates the bug is not being worked on and is not allocated. The bug is now "in the Mer backlog". | # Otherwise the bug is set to NEW and assigned to the "not-taken" user. This indicates the bug is not being worked on and is not allocated. The bug is now "in the Mer backlog". | ||
| Line 29: | Line 29: | ||
If there is enough information to work on and there are no blockers: | If there is enough information to work on and there are no blockers: | ||
# Developer submits package to Mer BOSS and documents changelog and/or commit properly (ie "fixes MER #1234") | # Developer submits package to Mer BOSS and documents changelog and/or commit properly (ie "fixes MER #1234") | ||
| − | # Developer marks bug | + | # Developer marks bug RESOLVED/FIXED (move this to RESOLVED/INREVIEW when we have automation) |
== Blocked ?? == | == Blocked ?? == | ||
| Line 50: | Line 50: | ||
= Automation = | = Automation = | ||
| − | # If Mer BOSS accepts the request the bug is set to | + | # If Mer BOSS accepts the request the bug is set to RESOLVED/FIXED |
| − | # If Mer BOSS rejects it the bug is set to | + | # If Mer BOSS rejects it the bug is set to RESOLVED/REJECTED until a subsequent review succeeds. Then the bug is RESOLVED/FIXED. |
# When BOSS accepts the request it logs the commit message and review link | # When BOSS accepts the request it logs the commit message and review link | ||
| − | Should BOSS only set | + | Should BOSS only set RESOLVED/FIXED from RESOLVED/INREVIEW or RESOLVED/REJECTED? Maybe 'ASSIGNED' too so that the developer doesn't have to explicitly close the bug? |
| − | What happens if the developer hasn't set the bug to | + | What happens if the developer hasn't set the bug to RESOLVED/INREVIEW? Should BOSS reject the review? How does the review get re-submitted |
Maybe: | Maybe: | ||
| − | # If the bug is in ASSIGNED state when a request is received, the bug is set to | + | # If the bug is in ASSIGNED state when a request is received, the bug is set to RESOLVED/FIXED and a link to the review is inserted in the bug log. |
# If bug is not in OPEN status (New, assigned, needinfo, reopened, waiting) or resolved FIXED (eg. duplicate, wontfix, etc... or verified or closed) the request MUST fail but we do not document the failure in the bug report | # If bug is not in OPEN status (New, assigned, needinfo, reopened, waiting) or resolved FIXED (eg. duplicate, wontfix, etc... or verified or closed) the request MUST fail but we do not document the failure in the bug report | ||
Revision as of 21:09, 4 January 2012
This page describes the Bug Lifecycle for Mer Core bugs.
(There may be variations for other products - tbd)
Mer bugs are recorded in https://bugs.merproject.org/
Contents |
Lifecycle and States
Note https://bugs.merproject.org/page.cgi?id=fields.html#bug_status describes expected usage of NEW/UNCONFIRMED and the 'reset to NEW' behaviour when the assignee is changed. If this behaviour is not desired we need to find time to maintain and support the modified bugzilla :)
Creation
- Select the appropriate Product. https://bugs.merproject.org/describecomponents.cgi should help.
- Now select the product specific Component. For Mer Core note that components are packages and "Other" or "package-groups". Use "Other" if you're not sure and Triage will fix it. (COMMENT: This is going to get messy as packages are renamed, deleted and added. Should this use a Tag instead?)
- A bug is raised and automatically assigned to the "needs-triage" user. The status should be "UNCONFIRMED"
Triage
- At the triage meeting the bug is reviewed and the priority/severity will be set and any obviously missing/wrong fields will be corrected.
- If the bug has too little information the status may be set to NEEDINFO.
- Triage will periodically review NEEDINFO bugs that are not responded too
- The assignee is kept as "needs-triage"
- Guideline for NEEDINFO is to close as INVALID after 4 weeks in NEEDINFO state with no response from reporter.
- If the bug is obviously invalid it may be RESOLVED/ appropriately.
- Otherwise the bug is set to NEW and assigned to the "not-taken" user. This indicates the bug is not being worked on and is not allocated. The bug is now "in the Mer backlog".
- A developer 'takes' a bug by setting the assignee. The bug is then "in the users backlog". The status may be kept at NEW in which case weekly 'nag' reports will be sent to the assignee. If you don't like this, don't take bugs until you're ready to work on them.
- When the developer starts working on the bug/feature it is set to ASSIGNED. The bug is then "being worked on".
Being Worked On
If there is enough information to work on and there are no blockers:
- Developer submits package to Mer BOSS and documents changelog and/or commit properly (ie "fixes MER #1234")
- Developer marks bug RESOLVED/FIXED (move this to RESOLVED/INREVIEW when we have automation)
Blocked ??
If the bug is blocked because of another issue or more info is NEEDED then the bug s
Useful Reports
This section shows how to setup reports based on the above bugzilla usage.
None user-specific queries
Mer Bugs waiting
To see bugs waiting for someone to look at them, in priority order.
User-specific queries
Bugs I'm working on
Bugs I've claimed but not started
My Blocked Bugs
Automation
- If Mer BOSS accepts the request the bug is set to RESOLVED/FIXED
- If Mer BOSS rejects it the bug is set to RESOLVED/REJECTED until a subsequent review succeeds. Then the bug is RESOLVED/FIXED.
- When BOSS accepts the request it logs the commit message and review link
Should BOSS only set RESOLVED/FIXED from RESOLVED/INREVIEW or RESOLVED/REJECTED? Maybe 'ASSIGNED' too so that the developer doesn't have to explicitly close the bug? What happens if the developer hasn't set the bug to RESOLVED/INREVIEW? Should BOSS reject the review? How does the review get re-submitted
Maybe:
- If the bug is in ASSIGNED state when a request is received, the bug is set to RESOLVED/FIXED and a link to the review is inserted in the bug log.
- If bug is not in OPEN status (New, assigned, needinfo, reopened, waiting) or resolved FIXED (eg. duplicate, wontfix, etc... or verified or closed) the request MUST fail but we do not document the failure in the bug report
Release handling:
- When a release is triggered any bugs mentioned in the release notes have their status automatically changed to RELEASED, a comment with a link to the image is created and the Target Build value is set to match appropriate release.
Later still:
- QA review the release and for each bug marked RELEASED, either change to VERIFIED or re-open
Note that eventually, both FIXED and RELEASED statuses would require specific credentials to be modified.
Bug Fields
(* for mandatory, _x_ for default value)
- Product (needing a short description as a default information) *
- The main area of Mer. See https://bugs.merproject.org/describecomponents.cgi for details
- Component (needing a short description as a default information) *
- Product specific list. For Core it contains all packages and some extras.
- Mer Release / Version
- This describes the image/release the error was found in. 0.YYYYMMDD.number-for-image-for-a-day, like 0.20111020.4. This field is currently fairly useless as it is not updated.
- Priority (High, Normal, Low, _Undecided_)
- High - Known to be important.
- Normal - Most bugs
- Low - Nice to have
- Severity (Critical, Major, _Normal_, Trivia, Enhancement, Task)
- https://bugs.merproject.org/page.cgi?id=fields.html#importance
- Enhancement adds functionality
- Task is usually a non-bug
- Summary
- The summary should get across key points. It may be changed by Triage.
- Description
- The main bug report
- Assigned To
- Set to the person working on the bug
- "need-triage@merproject.org" means the bug will be dealt with by Triage
- "not-taken@merproject.org" means developers are free to take these bugs as they've been sanity checked by the triage.
- QA contact
- Not used
- Keywords
- supported hardwares (i486/i586/ARMv6/ARMv7 softfp/ARMv7 hardfp/etc)
- Target build
- still open is this weekly basis or?
- Depends on
- List of other bugs/tasks
- Blocks
- List of other bugs/tasks
- Status
- New - The bug has been assigned but not accepted. It's in the user's backlog
- Needinfo
- Assigned
- TriagedUpstream - there's no need for waiting status, if something needs to be fixed first, the dependency is there
- Resolved - all the resolutions need to have comment as mandatory
- - fixed : means the code has been submitted for inclusion
- - samecause : having exactly same root cause than earlier reported bug
- - duplicate : is the same bug than earlier reported bug
- - worksforme : Test case provided does not result in the same problem. Use with care and consideration
- - invalid : For some reason the bug is not valid. Use with care and consideration
- - wontfix : The bug is valid/understood but won't be fixed due to some policy or decision. Use with care and consideration
- - codeavailable : there's fix but it can't be integrated yet
- Released : The bug is in a given release.
- Verified (comment mandatory) : The bug has been tested by QA or reporter.
- Reopened (comment mandatory) : The bug has recurred after being fixed.
- Closed : ???
