Received: by 10.192.165.156 with SMTP id m28csp1116811imm; Mon, 16 Apr 2018 14:30:15 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/N3qgswZ+SIAvaZI5fhwaV8/ZTqF7A9LnG88JVmEqwXOvmDVyu/utwij28DraJhai58I2h X-Received: by 10.99.112.93 with SMTP id a29mr10802131pgn.202.1523914215819; Mon, 16 Apr 2018 14:30:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523914215; cv=none; d=google.com; s=arc-20160816; b=KuLlcCcM8Do9mp6gx2V8R2gzh8Kx8ZKziXsCeqLGZe+K8gkcHIOe6YB9IAK0t0Cdxu UW9dygKnr0oWZQhAgIpEVo9aq/Qhwv13zygG4BlVgHjRnqSmWtjIK0YOePSnPcySKmz9 X8ZfUnycUBM/42uOkjb8qkJjNhCxfmhOsbwZFCCH+jQjox4HsKXTlH1YGMUJYLoV+6m3 se/qKHlaiIb7EnU7wA4+CM7wQgOBhRqrpMG9JyN37k312R4ljr3voPtTOwnKYDXeW19J 9kUsqESAJTgOreU3uJfLas/zKkGSPo//k4y7BkLijI+o0NxqdD9Kp/RqoFvTZc2ZbgvV eQvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=5rHhCxf1BFZch9jIwi3yunu9NfcajUGD3773XrUx3tA=; b=OJMzbaUePrucjXrE/icITQl2GNom1AvE0907VRVy+LUwyjmK0QmCiOWc/SoKDxM/RE wxgvHpnpvWdC3iP9r1GQ95ZZ+TMRzVRYkZTUN4zHo9XJs7dKk+pGHwvIZnex1JTVKXtA aPmztunS+5nm6YUYtyQ8VLdlIiOKHA6VkCXxoMOYNuw2If3cD769V0JBAgv7gpdB04Nu 8FluboFYUGHD+gSZ0s+yRLDsZBzEpUjqG9AO71OXv+gtcUmng72m+DvEQyDEB7ovJkcf mMELv4ZFp23+7TrQyuILuKBTN4fN7KUZTkXUcTVyza1rolh6gCjmTeZ5PBh9PvEppP7s hKdA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u3-v6si9677731plj.338.2018.04.16.14.30.01; Mon, 16 Apr 2018 14:30:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752670AbeDPV2w (ORCPT + 99 others); Mon, 16 Apr 2018 17:28:52 -0400 Received: from mx2.suse.de ([195.135.220.15]:33509 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751107AbeDPV2u (ORCPT ); Mon, 16 Apr 2018 17:28:50 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C167FAC19; Mon, 16 Apr 2018 21:28:48 +0000 (UTC) Date: Mon, 16 Apr 2018 23:28:44 +0200 (CEST) From: Jiri Kosina To: Sasha Levin cc: Pavel Machek , Linus Torvalds , Steven Rostedt , Petr Mladek , "stable@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , Cong Wang , Dave Hansen , Johannes Weiner , Mel Gorman , Michal Hocko , Vlastimil Babka , Peter Zijlstra , Jan Kara , Mathieu Desnoyers , Tetsuo Handa , Byungchul Park , Tejun Heo Subject: Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes In-Reply-To: <20180416211845.GP2341@sasha-vm> Message-ID: References: <20180416153031.GA5039@amd> <20180416155031.GX2341@sasha-vm> <20180416160608.GA7071@amd> <20180416161412.GZ2341@sasha-vm> <20180416170501.GB11034@amd> <20180416171607.GJ2341@sasha-vm> <20180416203629.GO2341@sasha-vm> <20180416211845.GP2341@sasha-vm> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 16 Apr 2018, Sasha Levin wrote: > I agree that as an enterprise distro taking everything from -stable > isn't the best idea. Ideally you'd want to be close to the first > extreme you've mentioned and only take commits if customers are asking > you to do so. > > I think that the rule we're trying to agree upon is the "It must fix > a real bug that bothers people". > > I think that we can agree that it's impossible to expect every single > Linux user to go on LKML and complain about a bug he encountered, so the > rule quickly becomes "It must fix a real bug that can bother people". So is there a reason why stable couldn't become some hybrid-form union of - really critical issues (data corruption, boot issues, severe security issues) taken from bleeding edge upstream - [reviewed] cherry-picks of functional fixes from major distro kernels (based on that very -stable release), as that's apparently what people are hitting in the real world with that particular kernel ? Thanks, -- Jiri Kosina SUSE Labs