In the last few weeks I have had the opportunity to watch releases of both Mozilla (1.0.3) and the Linux Kernel (2.6.11.8 aka Woozy Beaver). These are two of the largest open source projects in existence today and watching the release, build, bug tracking, and communication systems used by these projects was an eye opening experience. Why was it so interesting? Because these projects have strinkingly different ways to develop software.
Bug Tracking
Bugzilla is used pretty much exclusively by Mozilla to track issues, patches and the versions of software that they effect. Chase Phillips of Mozilla seemed very happy and comfortable working with the interface and understanding how and what all of the flags meant. It is a system that seems to work very well for the Mozilla crew.
Alternatively Greg KH said that the bugzilla.kernel.org rarely gets the attention that it needs and ofter goes ignored by kernel developers; although Andrew Morton does notify the proper subsystem maintainer if a bug has been sitting in the database too long. Instead the LKML is used as the primary place for tracking bugs and patches.
The kernel seems to have alot more “buy in” from its community of developers than Firefox does. And from my limited experience in working with open source communities, I think that the use of a mailing list over a BTS could make this difference. When filling a bug report people generally file and forget never having to get involved further. But with a mailing list you post your own problem and in response get to see everyone elses bugs and get introduced to the development process as patches poor into your mail box.
I realize that there are many other differences between the projects but I think that the dynamics of a mailing list are superior in getting people involved in a software project. But it has its draw backs- the LKML is historically a very harsh environment to get introduced to as the existence of Kernel Newbies and Kernel Mentors suggests. Furthermore some people do not feel comfortable working with mailing lists and smaller projects may miss out on bug reports from users if that is there only form of contact.
Source Code Management
Mozilla uses CVS and have some cool tools setup and integrated with it. Chase gave us a brief tour of Tinderbox (see below), LXR and Bonsai. If there is something that you want to know about the sourcecode these services would be a real help.
The Kernel deals in patches sent through email in particular Greg showed off some cool scripts that allow mbox files containing patches to be automatically parsed applying the patch after a dry-run and adding the patch writers information to the commits and changelog. It all seemed to be a very regulated and standardized process that was inspiriing to watch.
Recently the kernel developers have been working on git and from Gregs recommendation I have been following its development and all I can say is WOW the system is already usable after a month of work and it is looks to be one of those software products that is so practical, simple and pragmatic that in a few years it will become the standard. At the very least I have been having fun reading the source and watching it being developed.
Automated Builds
Mozilla’s Tinderbox system was impressive. The system was polished and well used by the developers. Particularly the integration with CVS and the ability to comment on who was taking charge and fixing the issue was neat.
The Kernel doesn’t have such a system although I have emailed the IA64 team which runs this service and I have been following the git mailing lists and playing with cogito. Maybe I will write one before someone points me to one that exists already :-).
Thanks Guys
Greg KH PCI, USB, I2C, Driver Core and 2.6.x.y maintainer.
Chase Phillips - release engineer for Mozilla
Dave Miller - system administrator for Mozilla
