gecko-dev/webtools/tinderbox2/README.NETSCAPE_PROCESS

The Netscape Development Process

Tinderbox was originally written at Netscape to support their software
development model. (Now fthe original Netscape development effort has
split into both the Netscape and Mozilla organization I will refer to
their efforts as if they were a single company called Netscape.  This
split does not effect the discussion of their processes.) Tinderbox
does not require that a company closely follow this model but the full
set of features are easily explained by the Netscape organization.
The implied "tinderbox development process" its a variant of
the "daily build" idea which is common in many companies.

At Netscape developers are geographically dispersed and often
telecommute from foreign countries.  There are hundreds of developers
working on a given product and this can lead to difficult
communication problems.  Developers get feature enhancement requests
and bug reports via a bug ticketing system.  The tickets are
prioritized by a Project Management Group call "Drivers".  The
developers work on the highest priority tickets in their queue and
when the changes are ready they look to the tinderbox web page to see
the current state of the source code.  If Tinderbox shows that some
tests do not work or code does not not compile then the developer must
wait until tinderbox indicates that everything is working. When a
developer checks in code tinderbox must verify that it compiles on all
architectures and all tests pass before a developer can leave that
night.

Should a programmer ever check in code which does not compile or does
not pass all tests then he is responsible for fixing the problem
immediately.  By looking at the tinderbox history it is easy to see
approximately the time the problem was introduced.  This limits the
set of possible changes which caused the problem to a small fraction
of the changes introduced that day and limits the number of possible
programmers who could have made this mistake to a small number.  Thus
the scope of the problem is clearly bounded in time, in source files
and in possible suspects.  If another developer was to check-in
additional changes at this time it would only confuse the issue and
possibly entangle the problem with other changes. No further checkins
are allowed until the problem is fixed.  All this information is
clearly visible to all developers and management on the tinderbox
web-page. When a problem occurs developers must quickly post a message
explaining that they are actively fixing the problem.  Since
development can not proceed until the problem is fixed it is in
everyone interest to solve problems quickly.

When all problems are cleared then the developer looks at the "tree
state" this indicates the management policies in effect.  At Netscape
the convention is that "Open" means checkins are allowed, "Closed"
Means checkins are allowed only with QA approval and "Restricted"
means that changes can only be made with Drivers approval.  The
approving person must be noted in the check-in comments along with the
bug ticket number which this fix was intended to address. Tree states
change according to managements need.  The restricted state is used to
ensure coordination between developers and the drivers group.  The
drivers group monitors the Tinderbox web-page to ensure that proper
check-in procedures are being carried out through out the day.

Usually the tree is "Open", there are some predictable times when the
tree enters another state.  Each morning the QA group closes the tree
and reopens it when they have verified the quality of the previous
days changes.  The Drivers group will restrict the tree for several
days when a major release of the product is imminent. Occasionally the
drivers group may need to restrict the ability of checkins
temporarily, like when a group intends to merge a large development
branch into the main branch.  During a complex merge it is important
that developers not involved in the merge do not check in their
changes and confuse the merging group.  Merging can take a few hours
to complete and it is easiest to do when the source code tree is
frozen except for use by the merging group.  At Netscape large merges
are typically done right after QA opens the tree.

By having the management policy clearly stated at the top of the
Tinderbox page everyone is aware of the current check-in requirements
and these can be quickly changed and the results communicated to all
developers if needed.  If there is a sudden need for an unexpected
policy change, it is still expected that every developer will know the
current policy at the moment they try to check code in.  In Tinderbox2
the tree state is also indicated with every check-in so it is possible
to look back at the history and see if George's last check-in was done
before or after the tree closed.

Each morning QA closes the tree and begins testing all of last nights
changes.  To ensure that QA has the support it needs to quickly finish
this work QA has a list of all the programmers who made changes
yesterday and a list of the changed files and check-in comment.  This
list of programmers is refered to as "The hook" and management
considers it imperative that everyone 'on the hook' be ready each
morning to fix or back out their changes.  When QA runs their daily,
mostly manual, tests no further checkins can occur till QA is
satisfied that the new code is at least as good as the old
code. Checkins are only made at QA's request to fix problems which
arise during testing.  Any problems which QA flags must be fixed or
backed out before the day's development can begin. Once QA approves 
daily build all programmers are expected to synchronize their code
with the latest known good sources. QA maintains a database of tree
opening times, so that it is easy to find older source code which has
been approved by QA. The "hook" is simply the list of all checkins
since the last time the tree was opened.

The focus for daily testing is on whether the set of day's changes is
good enough to be accepted into the main branch.  This is a separate
QA effort than the reporting of "bugs" which may take hours of QA time
to find and weeks of developer time to fix.  When QA is ready the tree
is opened and the day's development can begin. If there is ever a
serious problem with the development code it is always possible to
check out the version of the code at the time when the tree was opened.
This is the build which QA approved and is the last know good.

So there are daily QA milestones which ensure that the code works, and
that all developers can move forward.  The tinderbox tool monitors the
progress of all effort between milestones and reports what is going on
on a short time scale.  There are additional QA milestones which are
project dependent.  The longer term focus of these other milestones is
not an issue for the tinderbox system.