On Mon, May 26, 2008 at 5:41 PM, David Abrahams <dave@boostpro.com> wrote:

...
> I haven't yet thought about CTest, transforming CTest XML to
> bitten-palatable format, automatic generation of build/test recipes
> from cmake, or the possibility of some entirely different test-running

> mechanism than ctest. For what I have been doing, dummy builds

> suffice. I'm willing to switch to this though.... We could decide for
> now to bear with the extra administrative overhead of the current
> bitten and focus on this stuff instead. Comments?

I'd be more than happy to work on Bitten mods with you.

The Boost developers and Boost testers who are the end users need to see a unified system, with no apparent seams between parts done by the repository mechanism, build mechanism, test mechanism, reporting mechanism, and the scripting that ties the pieces together.

The only way that will happen is if there is close ongoing communication between the folks setting up the pieces. Doug and Troy are handling the repository and build parts. Dave is volunteering to work with them on the test and reporting parts. Who will handle the scripting parts?

For example, say a new tester comes on board. With the current testing system, here are the steps:

Install subversion, python, and a complier.
Download a python bootstrap program.
Run it. While there are many command line arguments, most have useful defaults. The only required arguments are things even a total newbie is likely to know, like the name they want to give the test runner.

From that point on the system is self-bootstrapping and self-updating, and is far more reliable than it used to be. Testers no long have to intervene manually for a new release or other changes. We need to achieve that same level of robustness for the replacement script.

--Beman