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
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
> 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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk