Bugs Lifecycle
Launchpad bugs are used to track known issues and defects in OpenStack software. They 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
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 trunk revision) of the software that you are running
When this is done, the bug is created with:
Status: New
Confirming
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
Importance: <Bug impact> (see below)
It is important to set this "Importance" field at this point in the process, as it will serve to prioritize the work for the rest of the stages.
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 set:
Status: Triaged
Bugfixing
At this stage, a developer will work on a branch that will contain the 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 branch for merging and get it reviewed.
After the branch is accepted
Once the branch is reviewed, accepted, and has landed in trunk, it will automatically move to:
Status: Fix Committed
- Milestone: Milestone the bug was fixed in
When the fix makes it into a milestone or release branch, it will automatically move to:
Status: Fix Released
Bugs Fields reference
Status
New |
The bug was just created |
Incomplete |
The bug is waiting on input from the reporter |
Confirmed |
The bug was reproduced and its importance was set |
Triaged |
The bug comments contain a full analysis on how to properly fix the issue |
In Progress |
Work on the fix is in progress, bug has an assignee |
Fix Committed |
The branch containing the fix was merged into trunk |
Fix Released |
The fix was released in an OpenStack milestone or release |
Invalid |
This is not a bug |
Opinion |
This is a valid issue, but it is the way it should be |
Won't Fix |
This is a valid issue, but we don't intend to fix that |
Importance
This must be set by 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 |
Data corruption / complete failure affecting most users, no workaround |
High |
Data corruption / complete failure affecting most users, with workaround |
Failure of a significant feature, no workaround |
|
Medium |
Failure of a significant feature, with workaround |
Failure of a fringe feature, no workaround |
|
Low |
Small issue with an easy workaround |
Any other insignificant bug |
|
Wishlist |
Not really a bug, but a small improvement |
Undefined |
Impact was not assessed yet |
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 want to fix the bug for, or the milestone/version it was fixed in.
Tags
Free-form tags you can use to search bugs with.