[Intel-gfx] ✗ failure: Fi.CI.BAT

[Daniel Vetter]

On Wed, Jan 13, 2016 at 10:20 AM, Mika Kuoppala
<mika.kuoppala at linux.intel.com> wrote:
>> But what with all the pass->dmesg-warn changes above? That's considered
>> BAT failure too, we can't afford to sprinkle warnings all over ... And
>> it's a bunch of different machines.
>>
>
> Forgot to address this one in previous mail. This patchset
> added more debug infra and enabled it for bsw/byt. So assumpion
> is that it did uncover a real problem thus the warns.
>
> Is the policy that if your debug infra reveals problems,
> you need to fix those problems?

We should discuss this in the next meeting (adding Annie/Jesse for
that), but personally I think adding new WARN/ERROR noise should never
result in BAT regressions. If your patch uncovers existing failures
even in BAT then imo the right approach is to first fix up things,
then apply the WARN patch to make sure we don't break things. The
problem is that once you have dmesg noise in a test, then no one will
notice additional noise and regressions. And that's how we got into
our mess last summer.

Also dmesg noise is not really acceptable anyway and needs to be fixed
(Linus/Dave will get grumpy).

If that takes too long because there's lots of warn, then maybe we
need to first add the new sanity check at debug level, just to help
with tracking down issues. We might need to improve CI reporting so
that debug level dmesg is still capture completely for BAT runs.

> If so, there is a chicken and egg problem as you don't
> always have access to hardware that your debug infra
> will cover.

Yeah, we need to enable manual submission to CI-machines. Abusing CI
as a test facility simply means that you're ok with blocking everyone
else with your CI result spam.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch