Received: by 10.192.165.156 with SMTP id m28csp1055864imm; Mon, 16 Apr 2018 13:18:46 -0700 (PDT) X-Google-Smtp-Source: AIpwx49Wu0/yUt0V+ian4PCZlhJ0i/vj+n52mH4FgE4etUvJ/856NJG6YkVeqlR8kutseqNOEhbQ X-Received: by 2002:a17:902:6045:: with SMTP id a5-v6mr9856168plt.138.1523909926614; Mon, 16 Apr 2018 13:18:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523909926; cv=none; d=google.com; s=arc-20160816; b=epUwHIZ4tUHU7Emwhz9F6Aew00lzzRHws3wZZqAHcXKRXF4zKR5r55aZNhEZrklxCI /ACJZKtd9TH/ys1DwlBpbCeruvkEbHUeFRMLKWHripNQQnBeTf3XOu21pt/twKktrl4l xa0WktaXFUrdzRy05R8jwB1SibvDTFYVAjno9A73uJ1EbUDzmhOTGUbVA/TM3yv6Jgui 90WIKJ7RuqzSXpIJJgeSqKS7OKdvPMriO9143Llkl4sYcXP8gJAiCrTwEZ+tmlhMEXh7 v/HZoFMAOWXwnNcNhwTI2Z61jgflPb+cn6fBqPiM+P/Ao/0N52msg1pbttcwj9AkV4yE tkuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=vWV2peSq3WY/yRludhAgaNbl5ZwuoXLiHnN9WuIFwN4=; b=vMwO+ZR8buKXJhL1F8UVxgG03V9wYYz7s0i1zrgrrq0EpUodg301kXtLhyJobkrP6C UOqpG3pMQxCJx3lIoERFGg9Pz3xV8gq81u2XHQ0VGmDMmLaPlp4DClGvTmGcYLF/lfAr 56vBesvNo2qDADJxResAaEh6qpXl0RdJ2KX0rxfLGnL85NDlxpSYi/YJfoT6pC7/a1QG icic1u03KL7JP61UY4/HoWlZh6iCP8IpQ6iCQh4JZnvzocxsULHtS/DXySZ+4hO0wGrk 01Jh+YoFbgAV9rGjgqx5R6ITi9jx6jSvjEbJFlcFuDXRG3M9jObCrqbXRYbU5RxQXL/s WA0A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=S1Zfvp4F; dkim=fail header.i=@linux-foundation.org header.s=google header.b=Pw9AEwXn; 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 y7-v6si12552409plt.287.2018.04.16.13.18.32; Mon, 16 Apr 2018 13:18:46 -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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=S1Zfvp4F; dkim=fail header.i=@linux-foundation.org header.s=google header.b=Pw9AEwXn; 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 S1751194AbeDPUR2 (ORCPT + 99 others); Mon, 16 Apr 2018 16:17:28 -0400 Received: from mail-io0-f180.google.com ([209.85.223.180]:35174 "EHLO mail-io0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750709AbeDPUR0 (ORCPT ); Mon, 16 Apr 2018 16:17:26 -0400 Received: by mail-io0-f180.google.com with SMTP id k8so8826118ioc.2; Mon, 16 Apr 2018 13:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vWV2peSq3WY/yRludhAgaNbl5ZwuoXLiHnN9WuIFwN4=; b=S1Zfvp4FPtUgmAP89PP1PF9x8dDIZUX14zkzQ/Ifb2kkCL/Ef7bYvILro7C8iX7rx8 ELFhW02hsA2sat2JcdAC5BR6wsRlEhX/JK1mJRTeZkorWgreY7De8gmTcGZtomFcDBoB 5BiNxlpoJyt0Ac8E0t1x/LWWIKzt0SizNyx39hDwolpYS1oGFfykGwssu/F0nmdMl3EE YZBEAqYNNf8poZUEBq9okpwduLqeI4NbjSHg3qHWtSIICDUyrPJgb2SJswsSk+Nk5nZ8 QslE8zSCD0StMzRgFIAFMBiE2M3gABXIBfVh+A7sHOVcI3X4bYboHUN6AccUTt9UxIB/ MOAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vWV2peSq3WY/yRludhAgaNbl5ZwuoXLiHnN9WuIFwN4=; b=Pw9AEwXn2UOqehbGwteMBHuR51WpreTsC6Cksb+Y9blhCRtTo9Z0+FZSYZuQRMbV5w yUR5el8HmyeMy/lPrE4I4/fEmdifvsAmwE3hPH0JbY5ykSjfYN6ssfXU+ZgErFKj89MU sVoFyqe8FeYdezP87a7k8JDj6mVpcEQxh8Qck= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vWV2peSq3WY/yRludhAgaNbl5ZwuoXLiHnN9WuIFwN4=; b=tddoSTo7OgARu6z8moqw2mcabwKSzXGKb/8IyiUCoHR06FzlR8I1aBVYuaDZqTeRH9 eAH+FdTufBSJgWGpmBhXBoyZurLxLfG+1qq2HH6s68QhBbaa7+DbpwNk5TRHn+2Ft1dt TmyF835dIBcG64H2LQz/EHHHn865LA5xrgHqmvduLz5igjx+oHyjxXwnKY5ukUw4/kQQ JFpZa6Q0QcF1xSVXDMllQT1SH1f5DN/T98wmeVU97e9godGyalwaWU0OTI5OrBKX2mFo aMkLqQIuKKNwHKgWYpkUDg5M40I3rSw4zXEVf+26VkBSvfmDb95V9jeK7n96TDL/eN36 rj7g== X-Gm-Message-State: ALQs6tAW2b6VbZLREJVS8FdzluE7nhSv7QekhEhiN+uEuYnoFTXvjZDN WvLq3L3PbzmUhQ0uJs77KA/3WTateRhX8Xz86U8= X-Received: by 10.107.47.215 with SMTP id v84mr10359523iov.48.1523909845485; Mon, 16 Apr 2018 13:17:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.95.15 with HTTP; Mon, 16 Apr 2018 13:17:24 -0700 (PDT) In-Reply-To: <20180416160232.2b807ff1@gandalf.local.home> References: <20180416153031.GA5039@amd> <20180416155031.GX2341@sasha-vm> <20180416160608.GA7071@amd> <20180416122019.1c175925@gandalf.local.home> <20180416162757.GB2341@sasha-vm> <20180416163952.GA8740@amd> <20180416164310.GF2341@sasha-vm> <20180416125307.0c4f6f28@gandalf.local.home> <20180416170936.GI2341@sasha-vm> <20180416133321.40a166a4@gandalf.local.home> <20180416174236.GL2341@sasha-vm> <20180416142653.0f017647@gandalf.local.home> <20180416144117.5757ee70@gandalf.local.home> <20180416152429.529e3cba@gandalf.local.home> <20180416153816.292a5b5c@gandalf.local.home> <20180416160232.2b807ff1@gandalf.local.home> From: Linus Torvalds Date: Mon, 16 Apr 2018 13:17:24 -0700 X-Google-Sender-Auth: Erv-6kGGes-59l8FJ-LL_mJ7QlI Message-ID: Subject: Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes To: Steven Rostedt Cc: Sasha Levin , Pavel Machek , 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 , Greg KH Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 16, 2018 at 1:02 PM, Steven Rostedt wrote: > > But this is going way off topic to what we were discussing. The > discussion is about what gets backported. Is automating the process > going to make stable better? Or is it likely to add more regressions. > > Sasha's response has been that his automated process has the same rate > of regressions as what gets tagged by authors. My argument is that > perhaps authors should tag less to stable. The ones who should matter most for that discussion is the distros, since they are the actual users of stable (as well as the people doing the work, of course - ie Sasha and Greg and the rest of the stable gang). And I suspect that they actually do want all the noise, and all the stuff that isn't "critical". That's often the _easy_ choice. It's the stuff that I suspect the stable maintainers go "this I don't even have to think about", because it's a new driver ID or something. Because the bulk of stable tends to be driver updates, afaik. Which distros very much tend to want. Will developers think that their patches matter so much that they should go to stable? Yes they will. Will they overtag as a result? Probably. But the reverse likely also happens, where people simply don't think about stable at all, and just want to fix a bug. In many ways "Fixes" is likely a better thing to check for in stable backports, but that doesn't always exist either. And just judging by the amount of stable email I get - and by how excited _I_ would be about stable work, I think "automated process" is simply not an option. It's a _requirement_. You'd go completely crazy if you didn't automate 99% of all the stable work. So can you trust the "Cc: stable" as being perfect? Hell no. But what's your alternative? Manually selecting things for stable? Asking the developers separately? Because "criticality" definitely isn't what determines it. If it was, we'd never add driver ID's etc to stable - they're clearly not "critical". Yet it feels like that's sometimes those driver things are the _bulk_ of it, and it is usually fairly safe (not quite as obviously safe as you'd think, because a driver ID addition has occasionally meant not just "now it's supported", but instead "now the generic driver doesn't trigger for it any more", so it can actually break things). So I think - and _hope_ - that 99% of stable should be the non-critical stuff that people don't even need to think about. The critical stuff is hopefully a tiny tiny percentage. Linus