From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2007-06-05 17:56:55
Beman Dawes wrote:
> Some tools, particularly those that are dependency based, are
> interesting to speculate about but are not essential. They can be safely
> ignored for now. And some of the needs may be met by off-the-shelf tools
> we don't have to develop or maintain.
> The most critical new (to us) tool would be test-on-demand. I've been
> very deliberately focusing on figuring out what is needed rather than
> where we get the tool or how the details work. Now that the need seem
> fairly firmly defined, we can start looking at what tools are available
> to meet those needs.
An excellent tool for test automation (and more) is the buildbot project
(http://buildbot.net/trac). It allows to set up a variety of schedulers,
triggered by a mix of timers as well as external events (such as check-in
It also allows to run builders (such as running test suites) on demand,
with suitable authentication in place.
As it happens, Rene has been working on a prototype to drive boost testing
> > I hypothesize that
>> the vast majority of the problems with our release process would go
>> away without a single change to our process, if only we had a robust
>> testing system.
> I think you have to change the process at least enough so that a stable
> branch is always maintained and developers can test their library's
> development branch on deman against the stable branch. The current
> "wild-west" problems in the trunk would not go away just because the
> testing system worked better, was more responsive, etc.
I don't quite agree. I strongly believe people would be more responsive to
failure notification if these reports would
1) be more reliable
2) provide more information about the failure (and context)
3) be more timely, to provide stronger evidence as to the likely cause
-- ...ich hab' noch einen Koffer in Berlin...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk