From: David Abrahams (dave_at_[hidden])
Date: 2005-03-21 10:07:06
Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
> David Abrahams writes:
>> Agreed, it's too hard, but that shouldn't stop us from talking about
>> what we would be doing in an ideal world. Accordingly:
>> - A health report for the latest release should always be available
>> on the website.
> Meaning user-oriented report showing whether she can use a specific
> library on a specific platform, or something else?
>> - Regressions from the previous release are nice to know but less
> I disagree. The are crutial for current Boost users, in particular in
> deciding whether to upgrade or not.
Okay, I buy that.
>> I realize we show both in one report, but this may
>> help us adjust our emphasis or coloring
> ? We didn't establish yet that we _want_ to adjust our emphasis.
Chill, my friend. I only meant, "should we decide it's neccessary."
>> (maybe it's already perfect in the user report; I don't know)
> I'm sure it's not perfect (and the user reports are currently in
> flux), but it's our current understanding that the needs of developers
> and users are different enough to warrant different
>> - A health report for the current state of the repository should
>> always be available on the website.
> I submit that a "health report" without regressions/explicit markup
> information is useless. What's your use case for it?
>> - There should be a way for a developer to request testing of a
>> particular branch/set of revisions
> This can easy get out of control, though. How do we ensure that not
> all our resources are used to test something on some branch and the
> main trunk still gets what it needs to be tested on a regular basis?
Prioritization, lots of computing resources, and incremental rebuilds.
>> - There should be enough computing power to handle all these tests
>> in a timely fashion.
> Right, and some mechanism to make sure that when it's not the case,
> the mainstream testing gets priority.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk