Jump to: navigation, search


Groundhog Bug Squashing Day

  • Date: February 2nd, 2012
  • Topic: OpenStack project bugs.
  • Key objective: Close as many bugs as possible over a day !

What ?

A bug squashing day is a bug day where all the OpenStack developer community focuses exclusively on trying to close as many bugs as possible. This can be done in multiple ways: you don't have to be an experienced Nova developer to participate, and those days are a great way to start joining the OpenStack community.

Where ?

The event happens mostly online, in a dedicated #openstack-bugsquash IRC channel on Freenode (that all participants are encouraged to join for the duration of the event). It can also happen in various places around the world, as the community informally gathers around food and drinks to squash bugs !

How ?

See DevQuickstart for instructions on getting a development environment up.



See how much of a difference you make: we will graph our progress during the whole day, using stats at: http://wiki.openstack.org/bugstats/


The number of open bugs filed against Nova grew from 200 to 500 in the last 6 months. Some of them no longer apply, some of them are easy fixes. Getting rid of them will allow us to have a more usable bug list as we get closer to the Essex release.

Even if their numbers are smaller, all other OpenStack projects are welcome to squash their bugs on the same day!

Getting Started Guide



Close old fixed bugs

Old bugs are nasty. Even when they are long dead, they clog bug views and render the lists unusable. Just look at old bugs and check if they still apply ! If they don't, close them as FixReleased (if you can pinpoint when they were fixed) or Invalid (if you can't).

Fix bugs

The best thing you can do on a bug squashing day is to kill a live one. Just look at the list of Confirmed or Triaged and pick your target. Submit a change that fixes it. Ask for review help on the channel.

Triage incoming bugs

It's sometimes hard to distinguish fresh bugs from false alarms. You can help by using your expertise or reproduction skills on New bugs. If you can confirm the issue, set the bug to Confirmed. If you can fix it, read the previous chapter. If you need more info from the reporter, set it to Incomplete. And if it happens to not really be valid, set it to Invalid !

Per-project objectives


  • Primary objective: Fall below 350 open bugs
  • Secondary objectives
    • New/Incomplete (untriaged bugs): under 40
    • Confirmed/triaged bugs: under 250
    • In progress bugs: under 40


  • Focus on code quality metrics, including code coverage and pylint
  • Improve system/integration testing with nova