W dniu 02.04.2012 21:45, Paul Larson pisze: > So what you are suggesting is basically that *all* tests become > out-of-tree tests?
Yes. Then the UI becomes streamlined, installation issues (if any) quickly fixed and everyone plays on equal ground. Then all current tests become linaro specific (if we so desire) and are installed by default in our jobs. > 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? LAVA test is perfectly cross platform. The part that relies on debian has been optional for a while. With my recent proposals it would also be possible to plug non-ubuntu package backends there. I can easily see fedora/rpm package backend and pure-python package backends being immediately useful. This would allow lava-test to be used on all major operating systems, to run unit tests of python software. Android is not part of this discussion but lava-android-test _can_ and _should_, similarly, work on all operating systems (including windows and osx), that have working adb client. > 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 We already have some blueprints on that topic. In the long term I'd like to merge both tools while unlocking a possibility of host-driven primitive-device tests that would allow bare-metal/silicon simluator/bootloader tests within the same common framework and command line interface. > 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. +1 but this should not affect the decision around this blueprint. > 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. You'll be happy to know that my recent work on fast models may bring us very close to that point. I'll explain later as it's already past 10PM but I'll provide a generic connection interface that has many (extensible by third party) implementation and drives the stack for both dispatcher and (possibly) lava-test. Thanks ZK -- Zygmunt Krynicki Linaro Validation Team _______________________________________________ linaro-validation mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-validation
