Revision as of 09:32, 4 June 2012

Launchpad bugs are used to track known issues and defects in OpenStack software.

Bugs reference

Here are the different fields available in Launchpad bugs, and how we use them within the OpenStack project.

Status

New

Incomplete

Confirmed

Triaged

In Progress

Fix Committed

Fix Released

Invalid

Opinion

Won't Fix

Importance

This should be set when the status reaches Confirmed stage. It is a combination of short-term impact (unavailability of a feature), long-term impact (data corruption, security breach), number of people affected, and presence of a documented workaround. Use these as guidelines:

Critical
High
	Medium
Low
	Wishlist
Undefined

Note that presence of Critical bugs will delay the release.

Assigned To

The person currently working to fix this bug. Must be set by In progress stage.

Milestone

The milestone we need to fix the bug for, or the milestone/version it was fixed in.

Bugs lifecycle

Bugs go through multiple stages before final resolution.

Reporting

When you find a bug, you should file it against the proper OpenStack project using the corresponding link:

Report a bug in Nova
Report a bug in Glance
Report a bug in Swift
Report a bug in Horizon
Report a bug in Keystone
Report a bug in Quantum

Make sure there is no bug already filed for the same issue, then enter the details of your report. It should at least include:

The release, or miletone, or commitid) corresponding to the software that you are running

When this is done, the bug is created with:

Status: New

Confirming & prioritizing

This stage is about checking that a bug is real and assessing its impact. If you are lacking information to properly reproduce or assess the importance of the bug, you should ask the original reporter for more information and set the bug to:

Status: Incomplete

Once you have reproduced the issue (or are 100% confident that this is indeed a valid bug), you should set:

Status: Confirmed

If you're a core developer or a member of the project bug supervision team, you should also prioritize the bug:

Importance: <Bug impact> (see above)

Debugging (optional)

This optional stage is about determining how to fix the bug and posting the solution in the comments. Sometimes the implementation of the fix will be straightforward and you would jump directly to bugfixing, but in some other cases, you would just post your complete debugging analysis and give someone else the opportunity of fixing the bug. Then you should ask a core developer or bug supervisor to set:

Status: Triaged

Bugfixing

At this stage, a developer will work on a fix. During that time, in order to avoid duplicating the work, he should set:

Status: In progress
Assignee: <yourself>

When the fix is ready, he will propose the change and get it reviewed.

Note that Gerrit will automatically set the status and assignee when a change is proposed that mentions the bug number.

After the change is accepted

Once the change is reviewed, accepted, and has landed in master, it will automatically move to:

Status: Fix Committed

When the fix makes it into a milestone or release branch, it will automatically move to:

Milestone: Milestone the bug was fixed in
Status: Fix Released

@@ Line 1: / Line 1: @@
 __NOTOC__
-= Bugs Lifecycle =
+<!-- ## page was renamed from [[BugsLifecycle]] -->
+Launchpad bugs are used to track known issues and defects in OpenStack software.
-Launchpad bugs are used to track known issues and defects in OpenStack software. They go through multiple stages before final resolution.
+= Bugs reference =
-== Reporting ==
+Here are the different fields available in Launchpad bugs, and how we use them within the OpenStack project.
-...
-* Status: ''New''
-== Confirming ==
-...
-* Status: ''Confirmed''
-* Importance: <Bug impact> (see below)
-== Debugging ==
-...
-* Status: ''Triaged''
-== During bugfixing ==
-...
-* Status: ''In progress''
-* Assignee: <yourself>
-...
-== After the branch is accepted ==
-...
-* Status: ''Fix Committed''
-...
-* Status: ''Fix Released''
-= Bugs Fields reference =
 === Status ===
@@ Line 69: / Line 32: @@
 === Importance ===
+This should be set when the status reaches ''Confirmed'' stage. It is a combination of short-term impact (unavailability of a feature), long-term impact (data corruption, security breach), number of people affected, and presence of a documented workaround. Use these as guidelines:
 {| border="1" cellpadding="2" cellspacing="0"
 |  ''Critical''
 |-
-|  ''High''
+|rowspan="2" | ''High''
+|-
+|-
+|rowspan="2" | ''Medium''
+|-
 |-
-|  ''Medium''
+|rowspan="2" | ''Low''
 |-
-|  ''Low''
 |-
 |  ''Wishlist''
@@ Line 83: / Line 51: @@
 |  ''Undefined''
 |}
+Note that presence of ''Critical'' bugs will delay the release.
 === Assigned To ===
-...
+The person currently working to fix this bug. Must be set by ''In progress'' stage.
 === Milestone ===
-...
+The milestone we need to fix the bug for, or the milestone/version it was fixed in.
+=== Tags ===
+Free-form tags you can use to search bugs with. Here is the list of [[BugTags|official tags]].
+= Bugs lifecycle =
+Bugs go through multiple stages before final resolution.
-=== Target to release ===
+=== Reporting ===
-...
-=== Tags ===
+When you find a bug, you should file it against the proper OpenStack project using the corresponding link:
-...
+* Report a [https://bugs.launchpad.net/nova/+filebug bug in Nova]
+* Report a [https://bugs.launchpad.net/glance/+filebug bug in Glance]
+* Report a [https://bugs.launchpad.net/swift/+filebug bug in Swift]
+* Report a [https://bugs.launchpad.net/horizon/+filebug bug in Horizon]
+* Report a [https://bugs.launchpad.net/keystone/+filebug bug in Keystone]
+* Report a [https://bugs.launchpad.net/quantum/+filebug bug in Quantum]
+Make sure there is no bug already filed for the same issue, then enter the details of your report. It should at least include:
+* The release, or miletone, or commitid) corresponding to the software that you are running
+When this is done, the bug is created with:
+* Status: ''New''
+=== Confirming & prioritizing ===
+This stage is about checking that a bug is real and assessing its impact. If you are lacking information to properly reproduce or assess the importance of the bug, you should ask the original reporter for more information and set the bug to:
+* Status: ''Incomplete''
+Once you have reproduced the issue (or are 100% confident that this is indeed a valid bug), you should set:
+* Status: ''Confirmed''
+If you're a core developer or a member of the project bug supervision team, you should also prioritize the bug:
+* Importance: <Bug impact> (see above)
+=== Debugging (optional) ===
+This optional stage is about determining how to fix the bug and posting the solution in the comments. Sometimes the implementation of the fix will be straightforward and you would jump directly to bugfixing, but in some other cases, you would just post your complete debugging analysis and give someone else the opportunity of fixing the bug. Then you should ask a core developer or bug supervisor to set:
+* Status: ''Triaged''
+=== Bugfixing ===
+At this stage, a developer will work on a fix. During that time, in order to avoid duplicating the work, he should set:
+* Status: ''In progress''
+* Assignee: <yourself>
+When the fix is ready, he will propose the change and get it reviewed.
+Note that Gerrit will automatically set the status and assignee when a change is proposed that mentions the bug number.
+=== After the change is accepted ===
+Once the change is reviewed, accepted, and has landed in master, it will automatically move to:
+* Status: ''Fix Committed''
+When the fix makes it into a milestone or release branch, it will automatically move to:
+* Milestone: Milestone the bug was fixed in
+* Status: ''Fix Released''
+= See also =
+* [[ReleaseCycle]]
+* [[BlueprintsLifecycle]]
+* [[BugTags]]

Difference between revisions of "Bugs"