Changes

I guess this is what I am doing here

===Step 2===

This step will be to set up buildbot at CDOT. This system will serve a dual purpose of having a local Buildbot system for use in CDOT as well as allowing me to test changes to buildbot. If having a local stable buildbot is found to be useful, an additional one can be set up. Initially, this local Buildbot will have a single CentOS Slave, though, as time goes on more slaves will be added.

I plan to put the buildbot master on Australia and use either KVM based Virtual Machines or bare metal machines.

This step involves making a change to buildbot which doesn't horribly break the system. By this release I would like to have at least one Windows and one OS X machine as slaves to ensure that nothing is broken for the individual build systems. This step will serve as a learning tool for my next step and make me familiar with the BuildBot codebase

As I understand it, buildbot uses [http://twistedmatrix.com/trac/ Twisted]'s twisted.python.log.msg() method to log everything. I will modify this function to interface with some sort of information gathering system and create a configuration option in buildbot to use this option. The patches which will accomplish this will be submitted upstream.

The log parser will need somewhere to put the information it finds in the logs. Currently, the best place to put this is a database. I will design the schema required for storing data. My goal is to have this be able to store information for different branches, each with their own history. This release will be in the form of a diagram illustrating the design.

This release will involve creating a way of getting data from the buildbot into the database. Currently, a parsing program is planned which will run on the logs of buildbot which have had timestamps added. Other options include having buildbot directly interface with the database and wrapping the individual build tools.

This step involves designing the UI for the trending information. It will include relevant information which is known to be representable from the data collected earlier.

I will implement this UI. I plan to make a web front end to the system.

===Step 3===

This step will not be broken down into distinct chunks yet as I would like to get familiar with buildbot and the overall build-test cycle before I start planning this part of the system. This step involves keeping track of historical information found during builds and their error logs. This portion of the system will help isolate recurring issues by making note of which machines are falling which test runs and why. A potential idea is to integrate some sort of 'learning' mechanism to help find patterns in build output which are known to be caused by a specific problem.