On 9 July 2012 12:54, Zach Pfeffer zach.pfeffer@linaro.org wrote:
IOn 9 July 2012 09:59, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
Hey everyone.
In light of discussion started by bug: https://bugs.launchpad.net/linaro-android/+bug/1022537 and duplicates I think we need to reconsider non-tests build variants.
I'd like to understand how that would work:
- Which builds need to be split to 'eng' and 'tests' builds?
- Which images are sent to LAVA for automatic testing?
- Which images are tested manually? (I don't suppose we'll test both)
- How do we re-visit the split (do we? how often? on what event?)
My current feeling is that:
0: we need to split all builds and slightly re-design the a-b.l.o front page to offer twin links 1: we use the 'eng' variant for LAVA, for now 2: we use the 'eng' variant for manual tests unless everyone agrees that they can reliably test 'tests' builds 3: we look at this policy every time we {loose,gain} {h/w acceleration,board type} and do a check-list each month during monthly planning.
Feel free to post your ideas and start the discussion. Thanks!
I think the best thing, given our available resources is just to stick with the "tests" builds and to characterize the slowness reported in the bug. Non-accelerated builds should be used in a batch mode anyway since interacting with them is frustrating at best. Perhaps we just call it a day on interactively testing any non-accelerated build, relying on LAVA for this testing.
Thanks for getting the discussion going Zyga. ;)
ZK
-- Zygmunt Krynicki Linaro Validation Team s/Validation/Android/
-- 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/#%21/linaroorg - http://www.linaro.org/linaro-blog