Large Free Software Projects and Bugzilla: Lessons from GNOME
Project QA
The GNOME project transitioned, during the GNOME 2.0 development and release cycle, from a fairly typical, mostly anarchic free software development model to a more disciplined, release driven development model. A key component of this transition was the move towards organized use of bugzilla as the central repository for quality assurance and patch tracking. This was not a process without problems- hackers resisted, QA volunteers did too little, or too much, we learned things we need to know too late, or over-engineered the process too early. But as a result of the experience, GNOME's latest releases have been more stable and reliable than ever before.
This paper will focus on two key components that made the GNOME QA model successful: developer/QA interaction and QA process. Falling into the first category, we'll discuss why GNOME developers bought in to the process, how bugzilla was made easier for them and for GNOME as a whole, and why they still believe in the process despite having been under bugzilla's lash for more than a year. Falling into the second, some nuts and bolts: how the bugmasters and bug volunteers fit into the development process, how we coordinate, and how we triage and organize.
Finally and probably most importantly, the paper will look at how other large projects like the kernel and xfree86 use or don't use bugzilla, and suggest how GNOME's transitional experience might suggest avenues of experimentation and improvement for those projects.
