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 6DF6CF0A for ; Fri, 7 Sep 2018 09:07:08 +0000 (UTC) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 67B308B for ; Fri, 7 Sep 2018 09:07:07 +0000 (UTC) Received: by mail-io1-f67.google.com with SMTP id q4-v6so999006iob.8 for ; Fri, 07 Sep 2018 02:07:07 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20180904201620.GC16300@sasha-vm> <20180905101710.73137669@gandalf.local.home> <20180907004944.GD16300@sasha-vm> <20180907014930.GE16300@sasha-vm> <20180906224541.27a9c8fe@vmware.local.home> From: Daniel Vetter Date: Fri, 7 Sep 2018 11:07:05 +0200 Message-ID: To: Geert Uytterhoeven Content-Type: text/plain; charset="UTF-8" Cc: ksummit Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Bug-introducing patches List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, Sep 7, 2018 at 10:40 AM, Geert Uytterhoeven wrote: > On Fri, Sep 7, 2018 at 4:45 AM Steven Rostedt wrote: >> Another issue about having fixes sit in linux-next for some time after >> -rc5, is that by that time, linux-next is filled with new development >> code waiting for the next merge window. A subtle fix for a bug that >> wasn't caught by linux-next in the first place (how else would that bug >> still be around by rc5?) is highly likely not to catch a bug with the >> fix to that subtle bug. > > Or the issue may never show up in linux-next at all. > > With strict by-subsystem merge policies, splitting a complicated patch set > by subsystem and scheduling it for inclusion across multiple kernel > versions can be challenging. If anything slightly related is applied > independently, or due to a scheduling oversight or merge window miss, this > may lead to a regression in mainline that is never present in linux-next, > and usually only detected late, leading to a fix after -rc5. Aside: I'm still baffled at how much soc people split up their work. As you point out, testing becomes a game of luck, because integration happens only in the merge window for real. Anything I'm involved in I'm insisting on a proper topic branch that everyone pulls in, to make sure that we can test the full interactions when we actually feature-freeze before the merge window. Usually that means baking the merge into the drm side, because we do a lot more testing than others (e.g. upstream intel audio validation is done through the drm trees too - it doesn't work that great because it's post-merge only for sound). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch