|
Boost : |
Subject: Re: [boost] is review system in place is extremely slow? (was Re: [rfc] rcpp)
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2010-03-02 11:03:47
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On
Behalf Of
> K. Noel Belcourt
> Sent: Monday, March 01, 2010 9:28 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] is review system in place is extremely slow? (was Re:
[rfc] rcpp)
>
> > 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.
Of course - release(d) libraries must have priority.
It sounds as though just chucking all the 'candidate' libraries into the 'pot'
would push the cooking time over the top?
> That said, it would not represent particular hardship for us to run
> additional tests for the candidate libraries.
What mechanism would be sensible to test 'candidate' libraries separately?
Some weekly test run? With some pass/fail report?
Or is it best on rely on authors running their own tests whenever they make some
changes? So users should be able to rely on
WYSIWYG?
This would not provide the very valuable pass/fail list available for trunk.
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).
So how would you suggest this would work in practice?
Thanks again for your testing!
Paul
--- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk