We can always run a dedicate performance test suite, but not until someone can own it and keep on top of it.
Cheers,
Ross Mason
CTO, Co-Founder
MuleSource Inc.
On 10 May 2008, at 00:06, Andrew Perepelytsya wrote:
They weren't failing often by any means. Don't think an occasional environmental failure warrants their exclusion. The early feedback/alarm they provide is more important than having to kick bamboo sometimes :)
Andrew
On Fri, May 9, 2008 at 5:49 PM, Andreas Guenther <
aguenther@...> wrote:
Looking at the reason for the build failure I am questioning the existence of performance tests within our regular build test suite. We e.g. have StreamingSpeed and StreamingCapacity tests with the later one failing. It's definitely nice to have them but executing them as part of a frequent build on an unpredictable build system seems to be inappropriate IMO. How about deactivating them?
-Andreas
Bamboo [DEV] wrote:
The project Mule - Mule 2.0.x (JDK1.5) has the following 1 change by 1 author:
*Andreas Guenther* made the following changes at
Comment:
MULE-3318 - Changing the issue number since reason for failure changed an will be addressed in new issue.
/branches/mule-2.0.x/transports/vm/src/test/resources/mule-test-exclusions.txt (11719)
---------------------------------------------------------------------------------------
The build has 1 failed test and 2223 successful tests.
Click http://bamboo.mulesource.org/browse/MULE-MULEV20X-492 to find out more.
Thanks,
Bamboo
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
