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 < [email protected]> 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-repo-project > >> > > > > 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 > [email protected] > http://lists.linaro.org/mailman/listinfo/linaro-validation >
_______________________________________________ linaro-validation mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-validation
