Bug Lifecycle

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

1. Select the appropriate Product. https://bugs.merproject.org/describecomponents.cgi should help.
2. 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?)
3. A bug is raised and automatically assigned to the "needs-triage" user. The status should be "UNCONFIRMED"

Triage

1. At the triage meeting the bug is reviewed and the priority/severity will be set and any obviously missing/wrong fields will be corrected.
2. If the bug has too little information the status may be set to NEEDINFO.
   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 NEEDINFO state with no response from reporter.
3. If the bug is obviously invalid it may be RESOLVED/ appropriately.
4. 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".
5. If the bug is having Release_Blocker flag proposal the flag is granted/declined.
6. 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.
7. When the developer starts working on the bug/feature it is set to ASSIGNED. The bug is then "being worked on".

Useful Triage preparation commands

These need the perl Text:CSV module installed.

#info We'll start with the bugs: https://bugs.merproject.org/buglist.cgi?bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=trivial&bug_severity=enhancement&bug_status=NEEDINFO&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=TRIAGEDUPSTREAM&bug_status=REOPENED&email1=need-triage&emailassigned_to1=1&emailtype1=substring&query_format=advanced&order=bug_id

curl -s -k 'https://bugs.merproject.org/buglist.cgi?bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=trivial&bug_severity=enhancement&bug_status=NEEDINFO&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=TRIAGEDUPSTREAM&bug_status=REOPENED&email1=need-triage&emailassigned_to1=1&emailtype1=substring&query_format=advanced&ctype=csv&order=bug_id' | perl -MText::CSV -ne 'my $csv = Text::CSV->new (); $csv->parse($_); @r=$csv->fields();next if ($r[0]) =~ /bug/; print "#topic https://bugs.merproject.org/show_bug.cgi?id=$r[0] - $r[7]\n";'

#topic Moving on to tasks: https://bugs.merproject.org/buglist.cgi?emailassigned_to1=1&query_format=advanced&bug_severity=task&bug_status=NEEDINFO&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=TRIAGEDUPSTREAM&bug_status=REOPENED&email1=need-triage&emailtype1=substring&order=bug_id

curl -s -k 'https://bugs.merproject.org/buglist.cgi?bug_severity=task&bug_status=NEEDINFO&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=TRIAGEDUPSTREAM&bug_status=REOPENED&email1=need-triage&emailassigned_to1=1&emailtype1=substring&query_format=advanced&ctype=csv&order=bug_id' | perl -MText::CSV -ne 'my $csv = Text::CSV->new (); $csv->parse($_); @r=$csv->fields();next if ($r[0]) =~ /bug/; print "#topic https://bugs.merproject.org/show_bug.cgi?id=$r[0] - $r[7]\n";'

#info Task list is now: https://bugs.merproject.org/buglist.cgi?bug_severity=task&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=not-taken%40&emailassigned_to1=1&emailtype1=substring&query_format=advanced&order=priority%2Cbug_id&query_based_on=

#info Not taken bugs: https://bugs.merproject.org/buglist.cgi?bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=trivial&bug_severity=enhancement&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=not-taken%40&emailassigned_to1=1&emailtype1=substring&query_format=advanced&order=priority%2Cbug_id&query_based_on=

Being Worked On

Once the developer has made a change that she thinks is good enough,

1. The developer documents the changes appropriately in the changelog and commits (including the "- Fixes MER#123: Bug summary" line at least in the changelog, when fixing bugs)
2. The developer submits the package for review
3. The developer marks the bug as RESOLVED/FIXED (should be 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.

Automation

This section is speculative - there is no automation as of Jan 2012. Additional status values may be useful to record the relationship between the bug and the associated request.

Proposal:

1. If Mer BOSS accepts the request the bug is set to RESOLVED/FIXED
2. If Mer BOSS rejects it the bug is set to RESOLVED/REJECTED until a subsequent review succeeds. Then the bug is RESOLVED/FIXED.
3. 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:

1. 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.
2. 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:

1. 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:

1. 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 : ???

Flag

Release_blocker: This bug is release blocker, with high priority. If you find any, please propose flag for the bug. The flag is it's approved at triage or release mgmt on mondays/tuesdays. ? = request, + granted, - not granted. A request may be deferred if it's like to affect a future release but not this one.