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)
Jump to: navigation, search
(Strawman lifecycle)
 
(Useful Triage preparation commands)
 
(10 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
This page describes the Bug Lifecycle for Mer Core bugs.
 
This page describes the Bug Lifecycle for Mer Core bugs.
  
(There may be variations for other components - tbd)
+
(There may be variations for other products - tbd)
  
 
Mer bugs are recorded in https://bugs.merproject.org/
 
Mer bugs are recorded in https://bugs.merproject.org/
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 NEEDSINFO.
+
# 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 set to the reported (or other as noted in the bug).
## Guideline for NEEDINFO is to close as INVALID after 4 weeks in NEEDSINFO state with no response from reporter.
+
## Guideline for NEEDINFO is to close as INVALID after 90days in NEEDINFO state with no response from reporter.
 +
## Triage should check for aged NEEDINFOs
 
# 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".
 +
# If the bug is having Release_Blocker flag proposal the flag is granted/declined.
 
# 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.
 
# 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".
 
# 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";'
 +
 +
<nowiki>#topic Any unloved NEEDINFO? https://bugs.merproject.org/buglist.cgi?query_format=advanced&chfield=[Bug%20creation]&chfield=alias&chfield=assigned_to&chfield=cclist_accessible&chfield=component&chfield=deadline&chfield=everconfirmed&chfield=rep_platform&chfield=remaining_time&chfield=work_time&chfield=keywords&chfield=estimated_time&chfield=op_sys&chfield=priority&chfield=product&chfield=qa_contact&chfield=reporter_accessible&chfield=resolution&chfield=bug_severity&chfield=bug_status&chfield=short_desc&chfield=target_milestone&chfield=bug_file_loc&chfield=version&chfield=votes&chfield=status_whiteboard&field0-0-0=days_elapsed&bug_status=NEEDINFO&type0-0-0=greaterthan&value0-0-0=90</nowiki>
 +
 +
<nowiki>curl -s -k 'https://bugs.merproject.org/buglist.cgi?bug_status=NEEDINFO&chfield=\[Bug%%20creation\]&chfield=alias&chfield=assigned_to&chfield=cclist_accessible&chfield=component&chfield=deadline&chfield=everconfirmed&chfield=rep_platform&chfield=remaining_time&chfield=work_time&chfield=keywords&chfield=estimated_time&chfield=op_sys&chfield=priority&chfield=product&chfield=qa_contact&chfield=reporter_accessible&chfield=resolution&chfield=bug_severity&chfield=bug_status&chfield=short_desc&chfield=target_milestone&chfield=bug_file_loc&chfield=version&chfield=votes&chfield=status_whiteboard&field0-0-0=days_elapsed&query_format=advanced&type0-0-0=greaterthan&value0-0-0=0&ctype=csv' | 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";'</nowiki>
 +
 +
#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 ==
 
== Being Worked On ==
  
If there is enough information to work on and there are no blockers:
+
Once the developer has made a change that she thinks is good enough,
# Developer submits package to Mer BOSS and documents changelog and/or commit properly (ie "fixes MER #1234")
+
# 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)
# Developer marks bug CLOSED/FIXED (move this to CLOSED/INREVIEW when we have automation)
+
# The developer submits the package for review
 +
# The developer marks the bug as RESOLVED/FIXED (should be RESOLVED/INREVIEW when we have automation)
  
 
== Blocked ?? ==
 
== Blocked ?? ==
Line 50: Line 73:
 
= Automation =
 
= Automation =
  
# If Mer BOSS accepts the request the bug is set to CLOSED/FIXED
+
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.
# If Mer BOSS rejects it the bug is set to CLOSED/REJECTED until a subsequent review succeeds. Then the bug is CLOSED/FIXED.
+
 
 +
Proposal:
 +
 
 +
# 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
 
# 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?
+
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 CLOSED/INREVIEW? Should BOSS reject the review? How does the review get re-submitted
+
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 CLOSED/FIXED and a link to the review is inserted in the bug log.
+
# 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
  
Line 128: Line 155:
 
: Reopened (comment mandatory) : The bug has recurred after being fixed.
 
: Reopened (comment mandatory) : The bug has recurred after being fixed.
 
: Closed : ???
 
: 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.

Latest revision as of 09:56, 4 June 2015

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

[edit] 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 :)

[edit] 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"

[edit] 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 set to the reported (or other as noted in the bug).
    3. Guideline for NEEDINFO is to close as INVALID after 90days in NEEDINFO state with no response from reporter.
    4. Triage should check for aged NEEDINFOs
  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".

[edit] 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";'
#topic Any unloved NEEDINFO? https://bugs.merproject.org/buglist.cgi?query_format=advanced&chfield=[Bug%20creation]&chfield=alias&chfield=assigned_to&chfield=cclist_accessible&chfield=component&chfield=deadline&chfield=everconfirmed&chfield=rep_platform&chfield=remaining_time&chfield=work_time&chfield=keywords&chfield=estimated_time&chfield=op_sys&chfield=priority&chfield=product&chfield=qa_contact&chfield=reporter_accessible&chfield=resolution&chfield=bug_severity&chfield=bug_status&chfield=short_desc&chfield=target_milestone&chfield=bug_file_loc&chfield=version&chfield=votes&chfield=status_whiteboard&field0-0-0=days_elapsed&bug_status=NEEDINFO&type0-0-0=greaterthan&value0-0-0=90
curl -s -k 'https://bugs.merproject.org/buglist.cgi?bug_status=NEEDINFO&chfield=\[Bug%%20creation\]&chfield=alias&chfield=assigned_to&chfield=cclist_accessible&chfield=component&chfield=deadline&chfield=everconfirmed&chfield=rep_platform&chfield=remaining_time&chfield=work_time&chfield=keywords&chfield=estimated_time&chfield=op_sys&chfield=priority&chfield=product&chfield=qa_contact&chfield=reporter_accessible&chfield=resolution&chfield=bug_severity&chfield=bug_status&chfield=short_desc&chfield=target_milestone&chfield=bug_file_loc&chfield=version&chfield=votes&chfield=status_whiteboard&field0-0-0=days_elapsed&query_format=advanced&type0-0-0=greaterthan&value0-0-0=0&ctype=csv' | 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=

[edit] 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)

[edit] Blocked ??

If the bug is blocked because of another issue or more info is NEEDED then the bug s

[edit] Useful Reports

This section shows how to setup reports based on the above bugzilla usage.

[edit] None user-specific queries

[edit] Mer Bugs waiting

To see bugs waiting for someone to look at them, in priority order.

[edit] User-specific queries

[edit] Bugs I'm working on

[edit] Bugs I've claimed but not started

[edit] My Blocked Bugs

[edit] 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.


[edit] 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.
Personal tools