Behind the Curtain

What happens when a developer makes a change and pipes up, ``Hey, mozilla.org, please take this code?'' One of mozilla.org's most important roles is to draw lines as to what code is accepted and what is not. We must factor in a number of issues. First and foremost is merit. Is it good? Second, is it under a license that is compatible with NPL? We decided not to accept contributions that were not under a license compatible with NPL. Otherwise there would have to be separate directories, Chinese walls, and lots and lots of legalese for everyone involved. The potential for error goes into the stratosphere.

Since Mozilla is a highly modular code base, each major module, such as the Image Library or the XML Parser, have a designated ``owner.'' That person knows the code best and is the arbiter of what should go in to that module and what shouldn't.

Many module owners are Netscape engineers, but some are coming on board from the Net-at-large. When a module owner makes changes (for example, adding an API to the Image Library) the modifications are sent to mozilla.org for inclusion in distributions. If differences arise between a contributor and the module owner, mozilla.org performs as the arbitrator, making the final call -- always aware that if it stops playing fair, it will be ignored and someone else will usurp the duties.

Mozilla.org had to contend with the fact that there would be both internal Netscape developers and people on the Net working on their code. The methods used to work on code internally had to accommodate the Web and be accessible on all platforms, in all time zones. This was done with ``tree control'' performed by the tools Bonsai and Tinderbox.

``Bonsai'' is a tool that lets you perform queries on the contents of an archive. Like the front desk of a library, you can ``check in'' code you've worked on, or see what ``checkins'' have been made by others. In the background, it constantly runs the code, checking the code tree. If the tree breaks, it sends up a red flag, stopping further checkins until the problem can be identified. Logs can be pulled and problems traced to a particular time period. Previously used by Netscape developers in-house, it was erected on mozilla.org for use by developers around the world and could be used directly through the browser on any platform.

If you get more than ten developers together without tools, there is going to be an explosion. That's the theory behind ``Tinderbox,'' a program that keeps this potentially explosive situation under control. Tinderbox is a detective tool. It allows you to see what is happening in the source tree. It shows who checked in what (by asking Bonsai), what platforms have built successfully, what platforms are broken, exactly how they are broken, and the state of the files that made up the build so you can track down who may have done the damage.