You have chosen to sponsor your bid up to a maximum amount of .
The buildbot master configuration file (master.cfg) is just a plain python file defining certain vectors; we have one for our buildmaster here that has grown considerably with time, with a lot of repeated stuff (see attachment).
We want to clean it up, drawing inspiration from the one for the webkit project:
But we do not want to objectify all (buildsteps, factories and builders), only the buildsteps; basically there would be buildsteps such as get_source_step(reponame), compile_step(workdir), extract_step(), qmake_step(project), make_step(project), test_step(cfg_file) that wrap all the platform-dependent stuff - pick up the platform from sys.platform (we have linux2, win32 and darwin).
The idea (for example for compile_step) is that instead of having separate linux_compile_steps, linuxclang_compile_steps, osx_compile_steps and windows_compile_steps vectors, at the end we want to enter just:
compile_steps = [ compile_step("src"), compile_step("dms"), compile_step("fc"), ... ]
And finally the small enhancement: add additional builbot steps information to waterfall for the test_step class, see:
The information we want to add is the number of tests failed (that you can retrieve from the return code of runner.py if positive and less than 128) and a link to the report in the form: /test_reports/buildslavehostname/summary.xml and a link to the logs in the form /test_logs/buildslavehostname/
Versions: the buildmaster runs on debian 7 (wheezy) so buildbot version is 0.8.6 and python version is 2.7.3.
Testing: what you can do is testing with "buildbot checkconfig .". You can not test RUNNING it ("buildbot start ."), unless you have a buildbot with the very same config as ours, therefore we will take care of that. You can optionally test running it with a simple buildbot setup (i.e. only on your development environment).