On 3 April 2012 03:45, Paul Larson
<paul.larson@linaro.org> wrote:
So what you are suggesting is basically that *all* tests become out-of-tree tests?
To some extent, I +1 for making more test become out-of-tree test too.
Let say integrating an android test into lava-android-test:
1. android team member create the test tools
sometimes the test tools just an android shell script, but it also need to merged into lava-android-test
2. android team member understand the lava wrapper infrastructure
3. android team member need to understand python to write the python wrapper script.
It's very very simple for member who know python, but will be difficult for member who does not know python.
like the indent style, string format style, for/if sentence style
4. android team member need to submit a MP for the branch, and wait review/merge
5. android member need to wait lava-android-test deployed to production and then can try the test on production.
some times also need to wait the modification of android build.
And all the steps above will need LAVA member to support.
If we make the test out-of-tree, then we just need to define the rules for the test tools that lava support,
and android team member just need create the test tools obey the rules lava required.
They can use any language the like, shell, python, C, even assemble language if he like
And the monkeyrunner supported now in the lava-android-test is something like this.
android team member only need to create the monkeyrunner script obey the rule and commit it into their git.
then they can try the test from android build.
Thanks,
Yongqin Liu
Also, some of your rationale is around lava being cross-platform. Lava-test - which natively assumes ubuntu/debian is certainly not cross-platform. Also, how would this affect lava-android-test?
I actually think we need to rethink lava-android-test, lava-test, etc. This is, perhaps, a good blueprint topic for the next connect. There have been some who have even expressed interest in running host-side tests for things like bootloader testing, prompting previous discussions of yet another lava-test fork. This is kinda nuts to keep forking this thing. I'd really like to go back to a base framework and reconsider things that we thought were a priority in the original design.
I'm thinking that all of this can be driven from the host side. A transport could be established and specified and handed off to lava-test to drive the install steps, run steps, etc. It could be serial, ssh, adb, lava-client, whatever. Then parsing/bundling would happen host-side. Test definitions could possibly even be simplified a bit I think.
Thoughts?On Mon, Apr 2, 2012 at 9:57 AM, Zygmunt Krynicki
<zygmunt.krynicki@linaro.org> wrote:
W dniu 02.04.2012 16:30, Andy Doan pisze:
AFAIK there is no way to implement that on launchpad without spamming
everyone in the LAVA part of the team. Plus it does not address any of
the other issues I've raised. It certainly is not a single project for
the reasons I've outlined there.
> I think keeping this simplicity is important.
I don't think this will raise the complexity, if anything it will ensure
that the same level of user experience is provided to in-tree and
out-of-tree tests.
Thanks
ZK
--
Zygmunt Krynicki
Linaro Validation Team
_______________________________________________
linaro-validation mailing list
linaro-validation@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-validation