On 17/05/17 00:40, Chris Johns wrote:
On 16/05/2017 18:35, Sebastian Huber wrote:
On 16/05/17 10:28, Chris Johns wrote:
What we do need to do is make sure the test results express the true
state. If a test is broken it should fail. If it is tagged an
expected-fail we do not consider it a regres
On 17/05/2017 10:34, Gedare Bloom wrote:
On Tue, May 16, 2017 at 6:40 PM, Chris Johns wrote:
On 16/05/2017 18:35, Sebastian Huber wrote:
On 16/05/17 10:28, Chris Johns wrote:
What we do need to do is make sure the test results express the true
state. If a test is broken it should fail. If
On Tue, May 16, 2017 at 6:40 PM, Chris Johns wrote:
> On 16/05/2017 18:35, Sebastian Huber wrote:
>>
>> On 16/05/17 10:28, Chris Johns wrote:
>>>
>>> What we do need to do is make sure the test results express the true
>>> state. If a test is broken it should fail. If it is tagged an
>>> expected-
On 16/05/2017 18:35, Sebastian Huber wrote:
On 16/05/17 10:28, Chris Johns wrote:
What we do need to do is make sure the test results express the true
state. If a test is broken it should fail. If it is tagged an
expected-fail we do not consider it a regression.
Loosing test coverage simply be
On 16/05/2017 18:32, Sebastian Huber wrote:
On 16/05/17 10:28, Chris Johns wrote:
>You
>wanted more tests to run in the SMP mode if SMP is enabled. Now only 36
>tests are left over.
I think it is a reasonable expectation when you build an SMP RTEMS the
tests run with SMP enabled using all avail
On 16/05/17 10:28, Chris Johns wrote:
What we do need to do is make sure the test results express the true
state. If a test is broken it should fail. If it is tagged an
expected-fail we do not consider it a regression.
Loosing test coverage simply because a test uses a non-SMP feature
somehow
On 16/05/17 10:28, Chris Johns wrote:
>You
>wanted more tests to run in the SMP mode if SMP is enabled. Now only 36
>tests are left over.
I think it is a reasonable expectation when you build an SMP RTEMS the
tests run with SMP enabled using all available cores.
No, we don't run the tests usi
On 16/5/17 5:54 pm, Sebastian Huber wrote:
> On 13/05/17 00:30, Chris Johns wrote:
>> On 12/5/17 8:24 pm, Sebastian Huber wrote:
>>> Mark tests that require review due to
>>> CONFIGURE_DISABLE_SMP_CONFIGURATION.
>> If a test fails it fails. I feel the test results need to correctly
>> express the f
On 13/05/17 00:30, Chris Johns wrote:
On 12/5/17 8:24 pm, Sebastian Huber wrote:
Mark tests that require review due to
CONFIGURE_DISABLE_SMP_CONFIGURATION.
If a test fails it fails. I feel the test results need to correctly
express the failures and we should not masks them in the way. I do not
On 12/5/17 8:24 pm, Sebastian Huber wrote:
> Mark tests that require review due to
> CONFIGURE_DISABLE_SMP_CONFIGURATION.
If a test fails it fails. I feel the test results need to correctly
express the failures and we should not masks them in the way. I do not
agree with changes that suppress a fa
Mark tests that require review due to
CONFIGURE_DISABLE_SMP_CONFIGURATION.
Update #3020.
---
testsuites/libtests/block08/system.h | 1 +
testsuites/libtests/cpuuse/system.h| 1 +
testsuites/libtests/rtmonuse/system.h | 1 +
testsuites/libtests/termios05/init.c | 1 +
test
11 matches
Mail list logo
