mozilla-history/webtools/tinderbox2/Goals

USERS
-----

It is helpful to consider the types of users for this system and their
special needs.

1) Project Managers: not very technical will be administering the
project and need a GUI to help change various types of project
information (treestate, message of the day, etc).  They will also need
summary pages which will show them the current status of all the
projects which they are working on.  They may occassionally "drill
down" into the detailed status page but this will not be their primary
view of the tinderbox system.

2) Build Administrator: A system administrator who will be in charge
of setting up the build machines, configuring tinderbox and other
build systems (bugzilla, cvs, bonsai, etc).  A GUI would not be
helpful as local customizations may require small changes to the code.
Configurations need to be kept (mostly) in files which are separate
from the Tinderbox source code so that they can be version controled
and will not get stepped on when tinderbox is upgradded.

3) Developers: need to view the "state of development" and add notices
to the notice board.

Improvements needed from Tinderbox1
-----------------------------------

highly configurable design with multiple Version Control systems
possible (bonsai, raw cvs, perforce, continuious, clearcase) and
multiple modes of running possible (with no version control system
with no builds display).

clear programatic interfaces and better separation of functionality
into separate modules.

It should be possible to add hooks so that users get beeped when the
next good build goes through or that trouble tickets are automatically
opened when the builds fail.

Greater flexibility in setting status of builds.  We may need more
gradations of failure then just 'busted' or 'test-failed' to
distinguish the types of tests which have failed.

It should be possible to watch projects milestone progress via
tinderbox.  Each milestone could be recorded as a column which tests
for the features in the milestone.  When milestones are hit the column
turns green.  The project is over when all columns turn green.

generated html must be readable and help isolate programming errors.

all programmable configuration parameters should be stored easy change
and configure for novice users.

make better use of the perl data structures to mirror the way we wish
to use the data.  This will allow easier maintainabilty and allow for
more expansion of features.

popup windows should not be netscape specific.

Permanent data should be stored via datadumper so that the data and
datastrucutres are easy to read and debug. Currently this is a
performance bottle neck with a large percentage of our cpu time during
testing being spent in Data::Dumper::Dump.  I expect this to improve
when we install the newest version of perl.  The perl module Storable
is rumored to be much faster.  I wish to not add additional module
requirements at this time this will be configurable.

# dprofpp says that:
#	%64.8 of elapsed real time which is 66.25 seconds 
#	(out of 102.15 Seconds)
#	was spent in 3 calls to TinderDB::VC::apply_db_updates()

#	%58.0 of user time which is 11.05 seconds 
#	(out of 19.03 User/102.15 Elapsed Seconds)
#	was spend in 32878 calls to Data::Dumper::_dump()

#	System Time was negligable at 2.49 Seconds

All errors should be trapped and sent to log files.  Strange program
states should be explicitly checked for.

Databases should update atomically, no information should be lost due
to race conditions.

All modules (processmail, build, VC, Notices) should be able to be run
individually.  Modules should accept well defined text files as input
and produce text files as output.  This will greatly inhance the
ability to test each module in isolation and to quickly port modules
to new architectures.

The source code should be able to run using the standard Perl
libraries, as it can be difficult for some users to add libraries
which are not included in the perl distribution onto production
machines.

Put CVS keywords into all the source files so that when the software
is deployed, there is no doubt what version was checked out and where
the files are stored in the local version control system.

Pay closer attention to security.  Use taint perl to ensure that
harmful input does not get used in unexpected ways.  Keep the flow of
control clear and simple.