Re: [boost] Release Tools Analysis Part II: Developer Feedback Systems

From: Jason Sankey (jason_at_[hidden])
Date: 2007-09-05 00:40:27

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