On Mon, Jul 29, 2013 at 03:56:09PM +1000, Stephen Rothwell wrote:

> Did the 0 day tester find these?  If so, then maybe you should wait a
> while longer before adding these things to your published trees.  If not,
> then I wonder why not.

No, it didn't.  The latency from the zero day tester seems to be quite
variable at the minute - sometimes it's just not reporting things at
all before they get found and fixed otherwise, sometimes it's as
astonishingly prompt as ever and sometimes it's reporting things other
than build issues but not the build issues.

> Even so as a developer, you should not really be submitting patches that
> have not been at least build tested.   You can find out which files are

Right, I don't submit stuff that's not been build tested at all except
in unusual situations - the issues have been coverage and dependency
ones.

> affected by these config changes and then really simply do:
> (assuming an x86 native platform - adjust for cross compiling)

> $ mkdir ../test.obj
> $ make O=../test.obj allmodconfig
> <make sure that the CONFIG options got turned on>
> $ make O=../test.obj <files affected s/.c/.o/>

When I change source files I do take steps to ensure that they've been
built including variations on the above, this specific issue is a fairly
unusual situation.

> You don't need to do full builds to find most of this stuff.  Of course,
> this will not find link time errors or missing module symbols.

Yeah, unfortunately those issues are a good proportion of what gets
caught by this sort of testing that wouldn't get caught in normal
development so it doesn't seem worth doing something that won't at least
give a linking kernel.