Nova/BugTriage

= Nova Bug Triage =

Track how we are doing: http://138.197.2.61/

The triage of Nova bugs follows the OpenStack-wide process documented on BugTriage.

There is an open group you need to join to get permissions to set bug priorities: https://launchpad.net/~nova-bugs

There is also a weekly Nova bug meeting here: Meetings/Nova/BugsTeam

= Tags =

All new bugs should be tagged to reflect which part of Nova they are related to. The current list of tags can be found below. Note that it is fine for a bug to receive more than one tag if appropriate. Launchpad Query: Untriaged Bugs Without Tags

Once new bugs have been tagged, they should be triaged as described on BugTriage. To help make sure that the triage queue stays under control, the following table lists the people that have committed to regularly triaging bugs for a given tag. The official (and inofficial) tags are at: https://bugs.launchpad.net/nova/+manage-official-tags

How to Subscribe to Tags


= Weekly bug skimming duty =

Nova gets a lot of new bug reports each day. Each bug report needs to be skimmed if it is a valid report, if crucial information is missing and so on. The weekly bug skimming duty should spread the knowledge and effort of that task to multiple people.

Ocata Cycle

Newton Cycle

The duty includes:
 * Switch the bug to "incomplete" when crucial information is missing and ask the reporter to provide more information. This includes:
 * steps to reproduce
 * the version of Nova and the novaclient (or os-client)
 * logs (on debug level)
 * environment details depending on the bug
 * libvirt/kvm versions, VMWare version, ...
 * storage type (ceph, LVM, GPFS, ...)
 * network type (nova-network or neutron)
 * Close as "invalid" if it is a support request or feature request.
 * Switch to "confirm" if you could reproduce the described issue or can otherwise say that this bug report seems valid. This is not always possible for you because of missing resources like a ceph storage or something like that.
 * Add a tag (or more tags) if the report allows you to narrow down the area which potentially contains the issue. This should be the entry point for subteams to dig deeper to find the root cause and potential solutions.
 * Bring critical bugs to the attention of the other contributors. The #openstack-nova channel and/or a ML post is useful.

In short, do as much as possible before the expertise of the subteams is needed. Also, if you spot potential critical bugs, shout out in the #openstack-nova channel (for markus_z or one of the core reviewers).

Misc

A bug report template can be found at BugReportTemplate

= FAQ =

Below are the most frequently asked questions about the bug triage. Please attend the nova bugs team meeting if you have more questions.

Q: What's the goal of the bug skimming duty? A: In short, reduce the amount of work other developers have to spent to do a proper root cause analysis (and later fix) of bug reports. For this, close the obviously invalid bug reports, confirm the obviously valid bug reports, ask questions if things are unclear.

Q: Do I need to prove that a bug report is valid/invalid before I can set it to /  ? A: No. Sometimes it's not even possible because you don't have the resources. Looking at the code and tests often enables you to make an educated guess. Citing your sources in a comment helps the discussion.

Q: What's the best status to close a bug report if its issue cannot be reproduced? A: Definitively. Note: The status  is an open state and means "more information is necessary".

Q: How do I handle open bug reports which are  for too long? A: If it is in this state for more than 30 days and no answers to the open questions are given, close it with.

Q: ''How do I handle dependencies to other bugs or TBD features in other projects? For example, I can fix a bug in Nova but I need that a feature in Cinder gets implemented before.'' A: Leave a comment in the Nova bug report which explains this dependency and leave a link to the blueprint or bug report of the other project you depend on.

Q: Do I have to double-check bug reports which are  and have an assignee? A: Usually not. This bug report has an inconsistent state though. If a bug report has an assignee, it should be  and have an importance set.

Q: question? A: