Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751470AbdIMWQe (ORCPT ); Wed, 13 Sep 2017 18:16:34 -0400 Received: from mail-pf0-f180.google.com ([209.85.192.180]:44889 "EHLO mail-pf0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751128AbdIMWQb (ORCPT ); Wed, 13 Sep 2017 18:16:31 -0400 X-Google-Smtp-Source: ADKCNb6rhT4vDjQ8u5IJoFzNP+Dnv/8ZRKmhTK1L2hkK/11PeBy1cHuUPx+I60JIaVQrv9SFLUzzXg== From: Kevin Hilman To: Greg Kroah-Hartman Cc: "kernelci.org bot" , linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org, linux@roeck-us.net, shuahkh@osg.samsung.com, patches@kernelci.org, ben.hutchings@codethink.co.uk, stable@vger.kernel.org Subject: Re: [PATCH 4.13 00/27] 4.13.2-stable review Organization: BayLibre References: <20170912165308.904472972@linuxfoundation.org> <59b8666e.e2a9df0a.378a2.e18c@mx.google.com> <20170913010300.GA22427@kroah.com> Date: Wed, 13 Sep 2017 15:16:26 -0700 In-Reply-To: <20170913010300.GA22427@kroah.com> (Greg Kroah-Hartman's message of "Tue, 12 Sep 2017 18:03:00 -0700") Message-ID: <7hingmdz2d.fsf@baylibre.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 902 Lines: 24 Greg Kroah-Hartman writes: > On Tue, Sep 12, 2017 at 03:57:50PM -0700, kernelci.org bot wrote: >> stable-rc/linux-4.13.y boot: 210 boots: 7 failed, 200 passed with 3 conflicts (v4.13.1-28-g0a9a7505477b) > > 7 failures here, and 8 for 4.12, are these to be expected? They are expected in the sense that nobody seems to care about the defconfigs that are failing, so nobody is looking into the failures. Since almost all of these failures seem to be related to various defconfnig + kconfig-fragment builds that nobody is taking the time to fix, I'm going reduce the set of defconfig that are built for stable trees to just the in-tree defconfigs. That should greatly reduce the signal-to-noise for these stable reports. We can then add back defconfigs as needed, on the condition that someone has the time/energy to keep those configs working in stable trees. Kevin