So what you are suggesting is basically that *all* tests become out-of-tree tests?
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:
On 04/02/2012 07:20 AM, Zygmunt Krynicki wrote:
Hi, please have a look at [1] and discuss this on the mailing list.
[1]
https://blueprints.launchpad.net/lava-test/+spec/lava-test-dedicated-test-re...
I would prefer this stay as one project, but the "test_definitions" directory is thought of as a separate component that another team, Paul's, manage (bug triage, code review, and merge)
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