Aleksey Gurtovoy wrote:
I believe partly it is so because it's hard to see the progress behind the new libraries and compilers that nobody cares about that are populating the field with yellow cells. It's generally discouraging to work on something and don't see a visible improvement over a relatively short period of time.
My impression was that there has been a good progress during the last days. Some compilers already look very good which is a very different situation from a week ago. (e.g. Intel 8 is nearing 100%; all the remaining defects are reported as compiler defect!)
Another contributing factors are long turnaround times (basically 24 hours), and the fact that many patches that could be committed instantly are submitted to the list and have to be applied by somebody with CVS access, consuming precious time of both sides (the patch submitter and the developer).
I can just second that, it's sometimes very annoying when you don't find anybody for committing a fix! And of course it's waste of time.
Note that the problem with long regression cycles is *not* that it takes too long to run the tests -- Boost-wide reports effectively solve this problem by enabling the testing to be highly distributed without loosing a bit of the results' informativeness. Our average regression cycle is 24 hours because many the regression runners cannot afford running the test continuosly rather than once daily.
[...]
My tests (Intel 8 and cw 9) run now twice a day. Although I thought this is a reasonable interval, it wouldn't be any problem for me to activate more machines and run tests more frequently. I could also add the toolsets VC 7.1 (and perhaps VC 8).
As for the patches, I beleive everybody will win if we grant a few people who have been actively contributing the fixes write access -- for those who wants it, of course.
If my help is needed, I want :) Stefan