On 22 January 2013 04:09, Andy Doan andy.doan@linaro.org wrote:
On 01/20/2013 08:57 AM, Rob Clark wrote:
Btw, not sure if any of you have seen the 0-day kbuild setup that intel has..
https://lists.01.org/mailman/listinfo/kbuild
runs various builds for different archs on every commit with different configs, randconfig, etc. And various checks with sparse, smatch, etc. Seems kinda useful, and would be a worthwhile goal to get arm arch to the point of "it just compiles and boots" like x86 is, vs arm which has a lot higher tendency to be broken if you don't have the right kernel config, etc. I guess on x86, they boot test all the kernels too on VMs. Perhaps we could go one better with something tied in to lava?
Seems pretty interesting. This might be a nice joint-effort thing we(LAVA) could do with the infrastructure team.
Interesting...
My first reaction to this was "sounds like a CI problem", so we should make sure that our CI/LAVA tools can cope. Of course, working on CI means that everything looks like a CI problem :-)
I don't know if LAVA has priority queues, but this sounds like a good candidate for a low priority task; use spare compute time to automatically experiment, while users specific builds and tests get priority.
I expect that we will need some decent logic to do constrained random generation of configurations since there is no point testing configurations that definitely won't work. The logic would be easy enough, but the constraints need to be written. Do we have this information? If not, would the people who have it be able to provide it in a machine readable form?
It also sounds like a workflow problem waiting to be solved: * Claim triage of issue. * Which project does the bug belong to? o CI config generation o Kernel o Build tools o ... * Create a bug report, seeding it with data from the build. * Mark issue as one of: o Triaged o Viewed (I looked at this and I don't know what to do with it kick it back out into the triage queue, but for me, show as viewed).
I imagine that without the right UI to assist in these steps (+ any automation we can do) this will turn into a nice idea that gets little use. I am all for it as long as we can do it properly. It looks a lot like an email interface, but I like the idea of claiming an issue to avoid duplication of effort and claim/un-claim to be an action that isn't a mailing list announcement.