Aleksey Gurtovoy <agurtovoy@meta-comm.com> 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?
Yes.
- Regressions from the previous release are nice to know but less important.
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 emphasis/coloring/etc.
Agreed.
- 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?
None.
- 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.
Sure. -- Dave Abrahams Boost Consulting www.boost-consulting.com