On 5 June 2012 18:23, Alexander Sack <[email protected]> wrote:
> I feel stopping and rebooting and continuing with the next test is
> what we want to aim for.
>
> On this front I wonder if we should directly go for rebooting for
> _all_ tests to ensure that every test gets executed the same runtime
> environment.
>
> Big benefit is obviously that tests can then stop services, change
> runtime state etc. as much as they like without bothering about
> bringing the system back into a clean state.
>
> Would that be hard? Why wouldn't we do this?

Seems like a good idea in theory, but in practice it may cause testing
to take a long time. Plus, what constitutes a test boundary? I think
if we do the fail then restart then we get the best of both worlds,
we're able to run multiple tests and restart if we get the system into
a really weird state.

> On Tue, Jun 5, 2012 at 4:18 AM, YongQin Liu <[email protected]> wrote:
>> Hi, Zach
>>
>> Could you help to give some comment about the mail below?
>>
>> Thanks,
>> Yongqin Liu
>>
>>
>> On 28 May 2012 15:29, YongQin Liu <[email protected]> wrote:
>>>
>>> Hi, Zach
>>>
>>> I am now working on a bp that adding the timeout process for android test
>>> action in lava.
>>> I am not sure if we should reboot the android image when the test run for
>>> a time longer than expected.
>>> so I'd like to know your opinion which you want to do.
>>> a. stop the test and restart the android image, then continue the next
>>> test
>>> b. stop the test and continue the next test
>>> c. others
>>>
>>> Like we submit a job to lava for running "monkey,glmark2,0xbench" test on
>>> android,
>>> while glmark2 test runs for a longer time than expected(like in which case
>>> if we don't stop it it will run for ever).
>>>
>>> In this case which one would you like?
>>> reboot the android and continue the next 0xbench test,
>>> or just stopped the glmark2 test and continue to run the next 0xbench
>>> test?
>>>
>>>
>>> Thanks,
>>> Yongqin Liu
>>
>>
>>
>> _______________________________________________
>> linaro-validation mailing list
>> [email protected]
>> http://lists.linaro.org/mailman/listinfo/linaro-validation
>>
>
>
>
> --
> Alexander Sack
> Technical Director, Linaro Platform Teams
> http://www.linaro.org | Open source software for ARM SoCs
> http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog



-- 
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

_______________________________________________
linaro-validation mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-validation

Reply via email to