BugZappers/BugStatusWorkFlow

From FedoraProject

< BugZappers(Difference between revisions)
Jump to: navigation, search
m (ASSIGNED: rm link to specific header (since changed))
(update to reflect change: NEEDINFO is a flag, not a state)
Line 1: Line 1:
<!-- page was renamed from BugZappers/Workflow
 
-->
 
 
= Fedora Bug Life Cycle =
 
= Fedora Bug Life Cycle =
 
 
  
 
== Background ==
 
== Background ==
  
 
This bug state flow came as a result of the bug triage relaunch that started in January 2008.  This work flow was approved at the [http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20080124 meeting on January 24, 2008] .  As a work flow these are not hard and fast rules to impose on people.  Instead it is intended to bring more uniformity and predictability to the life of a bug.  If you have a good reason to break them, feel free.  This is the process the triage team will follow.
 
This bug state flow came as a result of the bug triage relaunch that started in January 2008.  This work flow was approved at the [http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20080124 meeting on January 24, 2008] .  As a work flow these are not hard and fast rules to impose on people.  Instead it is intended to bring more uniformity and predictability to the life of a bug.  If you have a good reason to break them, feel free.  This is the process the triage team will follow.
 +
 +
Updated 17 March 2009 to reflect changes to the NEEDINFO representation.
  
 
== Overview ==
 
== Overview ==
Line 44: Line 42:
 
<!-- a fix checked into bugzilla should require the insertion of the cvs diff for mods that are attempting to fix the bug.
 
<!-- a fix checked into bugzilla should require the insertion of the cvs diff for mods that are attempting to fix the bug.
 
-->
 
-->
 +
 +
== NEW ==
 +
 +
When a reporter files a bug, the report automatically starts out in a NEW state.  The triage team will be primarily looking at bugs in this state.  From this state, the triage team will change the status to:
 +
* ASSIGNED: The bug is well defined and triaged
 +
* CLOSED: Duplicate, not a bug, not part of Fedora, etc.
 +
* NEW but with NEEDINFO flag: More information needed from reporter before being ASSIGNED.
  
 
== NEEDINFO ==
 
== NEEDINFO ==
  
Bugs are placed in NEEDINFO by bug triagers when adequate information is missing to move the bug towards resolution.  NEEDINFO bugs are eligible for closure (changed to CLOSED) by the triage team after '''all''' of the following have been met:
+
The NEEDINFO flag is added by bug triagers or maintainers when adequate information is missing to move the bug towards resolution.  NEEDINFO bugs are eligible for closure (changed to CLOSED) by the triage team after '''all''' of the following have been met:
# Bug was original placed in NEEDINFO by a triager or package maintainer
+
# Bug was originally placed in NEEDINFO by a triager or package maintainer
 
# Requested information requested has not been provided
 
# Requested information requested has not been provided
# Bug has been in NEEDINFO for thirty (30) continuous days.
+
# Bug has been flagged NEEDINFO for thirty (30) continuous days.
  
A stock message will be used by all triagers for bugs meeting this criteria.  Stock bug triaging messages are found at:
+
A stock message will be used by all triagers for bugs meeting the closure criteria.  Stock bug triaging messages are found at [[BugZappers/StockBugzillaResponses]].
https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses
+
  
== NEW ==
+
Because NEEDINFO is a flag and not an exclusive state, these bugs can also simultaneously be marked as NEW, ASSIGNED, etc.
 
+
When a reporter files a bug, the report automatically starts out in a NEW state.  The triage team will be primarily looking at bugs in this state.  From this state, the triage team will change the status to:
+
* ASSIGNED--the bug is well defined and triaged
+
* NEEDINFO--additional information is needed from the reporter
+
* CLOSED--duplicate of an existing bug or another closure reason
+
  
 
== ON_QA ==
 
== ON_QA ==

Revision as of 15:58, 17 March 2009

Contents

Fedora Bug Life Cycle

Background

This bug state flow came as a result of the bug triage relaunch that started in January 2008. This work flow was approved at the meeting on January 24, 2008 . As a work flow these are not hard and fast rules to impose on people. Instead it is intended to bring more uniformity and predictability to the life of a bug. If you have a good reason to break them, feel free. This is the process the triage team will follow.

Updated 17 March 2009 to reflect changes to the NEEDINFO representation.

Overview

BugZappers BugStatusWorkFlow fedora-bug-lifecycle.png

Source: File:BugZappers BugStatusWorkFlow fedora-bug-lifecycle.odg


ASSIGNED

The triage team believes that this is a complete actionable bug. It contains:

  • the correct component
  • the correct product
  • enough information for the package maintainer to investigate the issue
  • enough information to research with upstream or fix the bug
  • applicable release blocker or tracker bugs

The reporter has has also included one or more of the following (as applicable):

  • clear steps describing how the bug occurred
  • clear steps describing how to reproduce the problem
  • stack trace for a crasher
  • various log files
  • AVC message for SELinux

See BugsAndFeatureRequests for more details.

CLOSED

Once a bug has been fixed and included in a new package in rawhide or the updates repo it should be closed. If so designated by the maintainer, Bodhi can automatically close a bug when the package moves from the updates-testing repo to the updates repo.

MODIFIED

When a maintainer has a fix for a bug checked into CVS the bug should be placed in the MODIFIED state. This is an indication that the fix is checked into CVS and has potentially been submitted to be built in a new package. Adding a link to package in koji is very helpful for adventuresome testers and the original bug reporter to verify the fix.

NEW

When a reporter files a bug, the report automatically starts out in a NEW state. The triage team will be primarily looking at bugs in this state. From this state, the triage team will change the status to:

  • ASSIGNED: The bug is well defined and triaged
  • CLOSED: Duplicate, not a bug, not part of Fedora, etc.
  • NEW but with NEEDINFO flag: More information needed from reporter before being ASSIGNED.

NEEDINFO

The NEEDINFO flag is added by bug triagers or maintainers when adequate information is missing to move the bug towards resolution. NEEDINFO bugs are eligible for closure (changed to CLOSED) by the triage team after all of the following have been met:

  1. Bug was originally placed in NEEDINFO by a triager or package maintainer
  2. Requested information requested has not been provided
  3. Bug has been flagged NEEDINFO for thirty (30) continuous days.

A stock message will be used by all triagers for bugs meeting the closure criteria. Stock bug triaging messages are found at BugZappers/StockBugzillaResponses.

Because NEEDINFO is a flag and not an exclusive state, these bugs can also simultaneously be marked as NEW, ASSIGNED, etc.

ON_QA

  • A bug automatically transitions to this state when an updated package is submitted to bodhi for a particular bug and the package is in the testing repo. This tells the bug reporter that a fix for the bug is available and that they should test the package. After testing the package the bug tester or original reporter should put feedback in bodhi and add a comment to the Bugzilla.
  • The VERIFIED bug state is not used by Fedora.

ON_DEV

This optional state is used to show that someone is working on fixing this bug. This is especially useful if there exists a team of maintainers for a package.

POST

  • This state is primarily used by developers working on virtualization and the kernel.
  • A bug is moved to the POST state (from ASSIGNED) when a patch has been attached to the bugzilla entry and the gate keeper is waiting for the patch to receive three ACKS. Therefore, POST means "a patch is ready, but not yet applied".
  • After the patch is applied to the rpm the bug state changes to MODIFIED.