|
Boost : |
From: Jason Sankey (jason_at_[hidden])
Date: 2007-08-18 21:47:58
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/). We make an automated build (or
continuous integration) server named Pulse. An ex-colleague of mine drew my
attention to this discussion (I have been out of C++ for a couple of years now
so did not pick it up myself). I thought that maybe there would be an
opportunity for collaboration here if boost community are interested.
First off, we offer Pulse licenses for free to any open source project (there
are no strings attached). In this more specific case, being a previous boost
user I had always thought that the project would be a great test for Pulse. One
of the main features of Pulse is to enable building and testing across multiple
environments (operating systems, build tools, runtime versions etc) which is
obviously a key requirement for boost. I also believe that Pulse offers a very
usable web interface in contrast to a lot of the open source alternatives.
In addition to a free license and the current features of Pulse (which I will
not bore you with here), we also realise we would need to add further features
and help with integration. For example, your requirements for supporting
different types of test failures are only partially available in the current
Pulse release (we indicate that a test has been failing since some earlier
build, but do not have a notion of "known" failures). Also, support for boost
build and test tools will need to be added, but this is quite simple (and is
already on our roadmap for existing customers).
In terms of how we benefit from the arrangement, I will be upfront. Most
importantly, as I mentioned, I believe that this will be a great test for Pulse
and will lead us to feature ideas that will solve real problems. Second, as a
previous boost user I am personally happy to give some time back. Finally, we
may get some wider exposure for Pulse in the boost community. Let me stress,
however, that this is not required in any way -- it is entirely up to the boost
team to decide what level of exposure would be appropriate. If it was a real
concern we could even rebrand the UI.
Thanks for your consideration, and I look forward to your feedback.
Cheers,
Jason
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk