Re: [boost] is review system in place is extremely slow? (was Re: [rfc] rcpp)

Subject: Re: [boost] is review system in place is extremely slow? (was Re: [rfc] rcpp)
From: K. Noel Belcourt (kbelco_at_[hidden])
Date: 2010-03-01 16:27:53

Hi Paul,

On Feb 28, 2010, at 9:47 AM, Paul A. Bristow wrote:

> You are not alone is having made similar suggestions before, which  
> I support
> (though I would urge to 'Keep is Simple Sir' leaving the review  
> manager and
> moderators to make up the rules as they go along rather than  
> setting up a
> complex set of rules.  It is ain't broke, don't fix it!).
>
> But nobody has yet responded to the vital question of whether there  
> are
> resources to support a parallel tree to trunk,
> in addition to sandbox, for what we are calling 'candidate'  
> libraries.  It
> really needs to have an identical structure,
> and tests which are run regularly, like trunk.  This will encourage  
> more users,
> who have an important, and often informed, voice in reviews.
>
> Can those good souls doing the thankless task of providing SVN  
> files and testing
> (thanks!) comment please?

As one of those souls, I'd point out that a full (not incremental)  
test of Boost trunk for one nightly toolset with fast hardware and  
network running 8 cores is at least an hour, much longer for some  
toolsets.  For people with less capable systems, scale accordingly.   
I mention this to reinforce that testing Boost is already a fair  
commitment in resources and I want to ensure that our core libraries  
continue to be well tested and not slighted testing resources at the  
expense of candidate libraries.

That said, it would not represent particular hardship for us to run  
additional tests for the candidate libraries.  But I would like to  
encourage broader participation in testing Boost as, for example, our  
tester may not be able to continue with Boost.  I think that  
developers that get core libraries into Boost should consider helping  
with the testing load, given that they now have a vested interest in  
seeing Boost succeed (perhaps candidate library developers could also  
offer up some resources as well).

-- Noel