Bug fixing in Gentoo: How we are performing 2010-03-07
I’ve been playing with matplotlib and Gentoo bug numbers from the last ~6 month to be able to see how we are performing at fixing bugs lately. This is the current output:
While I am surprised how many bugs we fix each day I am also shocked that each month almost 70 bugs go on top of the current pile.
What else can we read from that graph? It seems Gentoo’s users are willing to report bugs (which is cool) but its contributors cannot fully keep up with fixing them (which is less cool).
I am presenting this graph today to suggest that:
- Bugzilla stats have interesting things to tell
- Fixing bugs could use more attention, manpower and a better process in Gentoo
- The planned re-write of bugday.gentoo.org could play a keys role with improving the process
- A Gentoo Google Summer of Code project could work on software to continuously extract detailed bug statistics for us
- You can do neat plots using Python and matplotlib
[EDIT] The source code to produce above graph is now available.
This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-No Derivative Works 3.0 Germany License.
The GMN (and GWN) used to have detailed bugzilla statistics, the code for that should be available somewhere. Maybe you can use it, or base the GSOC project on it.
Also, thanks for revitalizing the bugday
It badly needs a boost to achieve its full potential.
I have this vague idea of creating an overall Gentoo dashboard that shows the status of everything Gentoo, not just bugzilla. Things like commit rates, bugs fixed and opened, forum post, etc over time.
[...] Bug fixing in Gentoo: How we are performing 2010-03-07 While I am surprised how many bugs we fix each day I am also shocked that each month almost 70 bugs go on top of the current pile. [...]
@Donnie: I also have a similar vague idea. As a user I feel it is hard to know when my bug is really a bug and when i’m just doing something stupid, which probably leads to bugs not being reported. This in combination with the fact that some piece of software that exists yet is not in portage doesn’t necessarily constitute a “bug”. It would be nice to have a separate system that is more of a state tracker than a database of bugs, thus keeping it separate.
I want an organized display of the current state and version of every upstream program, even those that aren’t in portage, and be able to contrast that with the current state of the portage tree. You could add tons of metadata about stability and the level of interest in writing/updating/maintaining certain ebuilds. This would be the ultimate to-do quick-reference list with the added benefit that not everything on the list is actually a bug so there’s no need to feel like you’re just bitching at the devs by reporting an issue without having the know-how to fix the problem.
I’ll probably have the knowledge to work on something like this after i’ve crammed my brain with xhtml & javascript this semester.