From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9A82BCB9 for ; Tue, 27 Jun 2017 18:41:22 +0000 (UTC) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 239891F2 for ; Tue, 27 Jun 2017 18:41:22 +0000 (UTC) Received: by mail-io0-f178.google.com with SMTP id h64so22911233iod.0 for ; Tue, 27 Jun 2017 11:41:22 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1498588234.18166.29.camel@HansenPartnership.com> References: <1de3c642-a4b7-1065-5c35-ba32866d471d@redhat.com> <20170627175321.GS21846@wotan.suse.de> <1498588234.18166.29.camel@HansenPartnership.com> From: Daniel Vetter Date: Tue, 27 Jun 2017 20:41:20 +0200 Message-ID: To: James Bottomley Content-Type: text/plain; charset="UTF-8" Cc: ksummit Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Bug reporting feedback loop List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, Jun 27, 2017 at 8:30 PM, James Bottomley 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