Bugs
Launchpad bugs and StoryBoard stories are used to track known issues and defects in OpenStack software.
This content has been moved to https://docs.openstack.org/project-team-guide/bugs.html
Contents
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 Cinder
- Report a bug in Neutron
- Report a bug in Heat
- Report a bug in Manila
- Report a bug in Murano
- Report a bug in Mistral
- Report a bug in the manuals
- Report a bug in the api documentation
- Report a bug in the community tools
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 milestone, 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 a proposed/* release branch, it will automatically move to:
- Milestone: Milestone the bug was fixed in
- Status: Fix Released
Bug list maintainers
In 2014, the role of a "bug czar" was proposed on the mailing list. Since most probably most projects face the same issues when managing their bugs, it makes sense that the bug czars of the different projects work together. Right now these are:
