Termite

Termite is the going to be the successor to both the Tinderbox and the buildbot. The best of both world into the new system. The system will allow the building of OpenOffice.org on a variety of platforms, optionally with fixes too for testing. There will be a cluster and community builders. This page is to gather requirements for Termite. The requirements will be put under headings for each user group.

Pre-requisites

User Groups

Who is going to use Termite?

What are the needs of these users?

Cluster Users

A large array of machines that repeatedly build ooo from dirty CWS.

Community Builders

Have their own machines for the more exotic build setups or testing of new Termite features.

• Build page should show a list of available CWS that can be built
• Build pages like http://ooo-staging.osuosl.org:8010/MacPort1/builds/50 should have the start/end times for each part of the process
• The ability to get the mean, max, min, mode, median and and other daft statistical measures for the build times of the individual buildbots.
• The ability to tell you which module is currently being compiled. n of m, where n is the current module and m is the total number of modules to be compiled.
• The ability to say why a buildbot is offline (software update, machine in use for something else)
• Better detection of connection and disconnection
• The ability to queue builds (when a machine is off-line)
• The ability to apply a specific patch, without it being included in a specific CWS (primarily for initial testing before a commit)
• The ability to see information about a buildbot when it is off-line

Testers

Check if builds work properly

• need to access builds when they are unable to create such builds themselves.
• when a build has failed, the ability to attach notes to the build, such as why the build failed and related issue numbers in the issue tracker, would prove beneficial when the Termite network is fully utilized.

Coders

Write code which is usually placed into a CWS

• need to check that their code will compile/run on other OS.
• run the test suite on any platform.

Feature Wishlist

• should not depend on permanent connection to a buildmaster
  • should allow for self-contained buildslaves (slave decides what to build & when to build)
  • should allow to just send the buildlogs via email
  • should allow the use of rsync or similar to send the log information, thus allowing a drop in the connection, whilst allowing the live logs when there is a connection.

• should offer a way to manage buildclusters
  • should allow to remotely start builds on a set of buildslaves
  • should offer a way to specify additional configure/build flags

• should present the build-results on a per cws-basis
  • should be easy to tell whether a cws was built successfully or not and on what hosts it failed/succeeded
  • should be able to flag CWSs as "dirty" (i.e. commit was made after the build was started)
  • should optionally offer a CVS/Bonsai integration for a commit-history for that cws (similar to tinderbox)

• should present the buildlogs in a summarized way

• should offer to display statistics about a build (buildtime, ...)

• Ability to add notes about a build
• Ability to attach issues to a build
• Ability to see what the pending build(s) is/are
• Build information pages, should contain a listing of the full configure line that has been used.
• The ability to select a specific set of languages to build