+|
+
+ |
+
+
+
+
+
+
+ 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:
+
+
+
+
+ - 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'.
+
+
+
- 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.
+
+
+
- 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.
+
+
+
- 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.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.
+
+
+
+
+
+
+
+ |
+
+