Hi David, David Abrahams wrote:
on Sat Aug 18 2007, Jason Sankey <jason-AT-zutubi.com> wrote:
David Abrahams <dave <at> boost-consulting.com> writes:
This part of my analysis focuses on the tools available for getting feedback from the system about what's broken. Once again, because there's been substantial effort invested in dart/cmake/ctest and interest expressed by Kitware in supporting our use thereof, I'm including that along with our current mechanisms. Although not strictly a reporting system, I'll also discuss BuildBot a bit because Rene has been doing some research on it and it has some feedback features. <details snipped>
I would like to add another possibility into the mix, if I may. I am a founder and developer at Zutubi (http://zutubi.com/)...
Jason,
As far as I'm concerned Boost would be more than happy to use your tools if it will save us labor. With no other immediate prospects for improving things, we're going to try to launch a project to re-do the reporting system as a Trac plugin, with something like an XML-RPC frontend that will accept results from the testing servers. If you are offering to set up a Zutubi system that tests Boost, and it can do the things we need in terms of reporting (like handle test markup), we could delay that project and give you a chance to get something going. Do you think that would save us labor in the long run?
Certainly, this is the idea in general. Software development teams are usually capable of creating their own automated build system, but it costs a lot of labour that is better spent on other things. The only real advantage to rolling your own is the complete customisability. I am confident that a lot of what you need will come out of the box with Pulse. Also, since part of the idea from our end is to push the boundaries of Pulse, we will be available to add features that are required. I can't promise immediate addition of all requested features (it is clearly not practical) but if there are showstoppers we will address them. Further, we continue to open up areas of extensibility in Pulse (like the remote API, and plugins in the coming version), so if members of the boost community want to bend it one way or the other it should be possible. In our opinion a key requirement of a build server is flexibility to integrate with all sorts of existing practices and tools. The next step from our end would be to build in some support for bjam and Boost.Test (I can have it done by next week) and then set up an initial server to show you what Pulse is about. This is the lowest risk way for boost in that you don't need to invest much effort to take a look. The main question is provision of hardware: do you have hardware available that you would like to host this demo on? If not, I am sure I can sort something out. I guess we can take these details off the list and post back once something is running to get some feedback. Cheers, Jason