Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Bug reporting feedback loop

[Daniel Vetter <daniel.vetter@ffwll.ch>]

On Tue, Jun 27, 2017 at 8:30 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>> But one day it comes that KOTD is not sufficient, and there is that
>> pesky delta on linux-next which *might* also have a fix for you.
>> Problem is booting linux-next can often fail.
>
> Just a minute: I'd like to question that assumption. -next is supposed
> to be all the upstream trees targetting the merge window.  Boot failure
> regressions in those trees are very rare.  Fine, not non-existent so
> that's why we run testing and inspection on them, but "often fail" is a
> mischaracterisation.  I think the correct characterisation would be
> "rarely fail", but I can compromise on "sometimes fail".

The merge window takes out about 30% of our CI machines when it lands
(not boot, also stuff like suspend/resume so a bit more than your
criteria here, but all because of issues outside of drm, we tend to
catch our own crap on our own machines). We probably should test
linux-next to catch this stuff earlier, but atm we just don't have the
time - just getting the -rc1 fallout back under control takes a lot of
time (e.g. we still have a e1000e regression fix in our CI branches
since the patch doesn't seem to go anywhere, despite nagging). I
wound't call this "rarely fails" when you can easily see the spacing
of merge windows in our CI stats. But maybe no one tests on random
piles of recent and semi-recent intel desktops and laptops, dunno.

Not sure what the solution would be since I'm pretty sure drm/i915
isn't innocent in taking out other systems, except much more testing
of linux-next (for which we simply don't have the machine time nor
people to triage the fallout right now).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch