You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

Tinderbox 2.0

Development Monitoring System
rewrite by Ken Estes

This document describes a rewrite of the original Tinderbox 1.0 development tool.

Tinderbox is the first program to allow developers and management to see at a glance what is currently going on in all aspects of the development process. The Tinderbox server prepares HTML pages which display the history of many different development variables. It shows at a glance the history of: whether the HEAD branch of the source code builds and passes all automated tests, who has checked code changes into the version control system, whether the source tree is open or closed and when the state of the tree last changed, what trouble tickets have been closed, notices and messages posted by the developers or project manager.

The new Tinderbox code is highly configurable and will allow you to work with many different types of version control or bug tracking systems. It is relatively easy to add new modules which work with other systems. It is also easy to configure Tinderbox to run without the displays that your organizations does not need or to run with duplicate modules if the need arises.

Here is a description of the main Tinderbox subsystems:

  1. Tinderbox is an automatic build master. The build module allows an organization to dispense with the dedicated employee whose title is 'build master'. A fleet of dedicated build machines continually run the compilations and any automated tests of the latest source code. Developers can see at a glance whether the most recent changes in the version control system will break the build of the product, break any automated style (lint) checks, cause the automated unit tests to fail or cause the code coverage of the unit tests to drop below a required minimum. These builds are not run daily as with most organizations but are run continually for immediate feedback. Each developer can monitor whether his changes break the automated build/tests and each developer can see at a glance which developer caused an problems which are being reported. The build/test logs are available at the click of a web link so that developers need not have access to the build/test machine/architecture to fix any compilation/test problems. Tinderbox allows the build organization to push back the responsibility of ensuring the code builds to the developer who just checked in the code. Anyone with a browser can see if the build failed and read what the error message was. Tinderbox does not prevent any development from occurring. Should it ever be necessary to allow development to proceed even though the tests are broken it is easy for developers to ignore the reports of failing tests and to configure Tinderbox to not display any tests which are not currently being monitored. Tinderbox does not enforce any development methodology it only displays the current 'state of development'.

  2. Tinderbox displays the history of recent changes to the code stored in a Version Control system. This allows developers to see at a glance which portions of the code are being changed and who is changing the code. It is no longer necessary to configure the Version Control system to mail each developer when changes are occurring. Any developer who needs to know what is going on with the sources can see at a glance what changes were made. When the builds/tests fail it is easy to figure out what person is responsible for the problem. The person who "broke the build" is any person who did a checkin between the last good build and the broken build. This quickly narrows the possible suspects and allows for transparent accountability for any problems. After the Project Manager closes the tree for further checkins all checkins appear in a shaded color (grey) so that it is easy to desert which checkins were made after the tree was closed and see of any checkin policies have been violated.

  3. Tinderbox box will soon display the trouble tickets which were closed. Since the changes in the code were likely made to fix bugs, it is convenient to have the current changes to the bug tracking system displayed on the Tinderbox pages.

  4. Since the Tinderbox web pages are a centralized place for Project information there is a "Message of the Day" for managment messages and a "Notice Board" where developers can post information of interest the project. Typically the notice board is used to announce when a developer makes major changes to the source code or to confirm that a recent build failure is being fixed or backed out.

How can I have the source so that I can run it on my own projects?

Please see our CVS page for information on using our CVS server. (The Tinderbox and Bonsai sources are currently only available via CVS.) 

               To check out the sources, you need to be running CVS 1.10 or later, and have your $CVSROOT set to

                    :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot

               The password for user anonymous is anonymous.

	cvs checkout mozilla/webtools/tinderbox2
Anyone can check out the sources via CVS, but only certain people have the ability to check in. Those people, basically, are the module owners and their delegates. Read our document on hacking mozilla to find out how to get the ability to check in.

Is there a mailing list or news group for Tinderbox?

We host some mailing lists and newsgroups at mozilla.org, to foster open communication in the developer community. We add new forums with some regularity, in response to the needs of you, the developers. What forums do you want? As new special-interest groups appear, we will create new newsgroups and mailing lists, or whatever seems most useful. Let us know. For an overview of the hottest newsgroup articles and threads, check out NewsBot.

Please see our Community page for information on subscribing to one of the mailing list and for the ground rules for participation in these forums. Please respect these rules, and each other.

The mailing lists and newsgroups described here are for Mozilla developers, not for end-users. These lists are for discussions related to the Mozilla source code, by and for the Mozilla developer community.

Since some people prefer newsgroups, and some people prefer mailing lists, we have created our discussion forums in pairs: both a newsgroup and a mailing list. Each one mirrors its mate: messages sent to one of the newsgroups will also show up in its corresponding mailing list, and vice versa. That way, you get your pick of whether you'd like to read the message via news or mail.
Mozilla-Webtools netscape.public.mozilla.webtools
mozilla-webtools@mozilla.org
unsubscribe

    Mozilla.org has developed several web-based tools that is used to help manage the code. These tools include Bugzilla (bug tracking), Bonsai (CVS queries), and Tinderbox (continuous automated builds). In the spirit of open software, the source of these tools is freely available, and people may work on them and use them for their own purposes. This forum is for discussions about these tools.