On 22 January 2013 04:09, Andy Doan <andy.d...@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.
--
James Tunnicliffe
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
