Revision as of 18:46, 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/

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". (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 NEEDSINFO.
1. Triage will periodically review NEEDINFO bugs that are not responded too
2. The assignee is kept as "needs-triage"
3. Guideline for NEEDINFO is to close as INVALID after 4 weeks in NEEDSINFO 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 CLOSED/FIXED (move this to CLOSED/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 CLOSED/FIXED
If Mer BOSS rejects it the bug is set to CLOSED/REJECTED until a subsequent review succeeds. Then the bug is CLOSED/FIXED.
When BOSS accepts the request it logs the commit message and review link

Should BOSS only set CLOSED/FIXED from CLOSED/INREVIEW or CLOSED/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 CLOSED/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 CLOSED/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 : ???

Bug Lifecycle