From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B32DCC433E0 for ; Sat, 8 Aug 2020 11:28:58 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7F1612224D for ; Sat, 8 Aug 2020 11:28:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ue2UD2xW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7F1612224D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 48D766E20B; Sat, 8 Aug 2020 11:28:57 +0000 (UTC) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by gabe.freedesktop.org (Postfix) with ESMTPS id A10D86E20B for ; Sat, 8 Aug 2020 11:28:55 +0000 (UTC) Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BF5BD221E5; Sat, 8 Aug 2020 11:28:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596886135; bh=vBFMhdAEamx/FNEl4l+v1WdLPZvkH2+eLo10uDinHqg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Ue2UD2xWyI1T6gnQ/OY0ZX3oh8RfImSbhbHzKASzdDO/Weq3v/FUFSeWJHskqyoTv 2hZ+k/CmDVj9NBVI/cEjmMB8FlTIOWThqmcerd6ksiGVBjBdhFd7n8bNENq/gvCBH7 vOa0vtQpd/5OHwJqEUKFWyiTd/2064kSZSXw6XBU= Date: Sat, 8 Aug 2020 13:29:08 +0200 From: Greg KH To: Daniel Vetter Subject: Re: WTF: patch "[PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header" was seriously submitted to be applied to the 5.8-stable tree? Message-ID: <20200808112908.GA3063898@kroah.com> References: <159680700523135@kroah.com> <20200808102512.GA3039253@kroah.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Krzysztof Kozlowski , dri-devel , armijn@tjaldur.nl, Gerd Hoffmann , Thomas Zimmermann , Alex Deucher , Dave Airlie , stable , Sam Ravnborg , Thomas Gleixner , Emil Velikov Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Sat, Aug 08, 2020 at 01:02:34PM +0200, Daniel Vetter wrote: > On Sat, Aug 8, 2020 at 12:24 PM Greg KH wrote: > > > > On Sat, Aug 08, 2020 at 11:13:54AM +0200, Daniel Vetter wrote: > > > On Fri, Aug 7, 2020 at 3:54 PM Thomas Zimmermann wrote: > > > > > > > > Hi > > > > > > > > Am 07.08.20 um 15:30 schrieb gregkh@linuxfoundation.org: > > > > > The patch below was submitted to be applied to the 5.8-stable tree. > > > > > > > > > > I fail to see how this patch meets the stable kernel rules as found at > > > > > Documentation/process/stable-kernel-rules.rst. > > > > > > > > > > I could be totally wrong, and if so, please respond to > > > > > and let me know why this patch should be > > > > > applied. Otherwise, it is now dropped from my patch queues, never to be > > > > > seen again. > > > > > > > > Sorry for the noise. There's no reason this should go into stable. > > > > > > We have a little script in our maintainer toolbox for bugfixes, which > > > generates the Fixes: line, adds everyone from the original commit to > > > the cc: list and also adds Cc: stable if that sha1 the patch fixes is > > > in a release already. > > > > > > I guess we trained people a bit too much on using Fixes: tags like > > > that with the tooling, since they often do that for checkpatch stuff > > > and spelling fixes like this here too. I think the autoselect bot also > > > loves Fixes: tags a bit too much for its own good. > > > > > > Not sure what to do, since telling people to "please sprinkle less > > > Fixes: tags" doesn't sound great either. I also don't want to tell > > > people to use the maintainer toolbox less, the autogenerated cc: list > > > is generally the right thing to do. Maybe best if the stable team > > > catches the obvious ones before adding them to the stable queue, if > > > you're ok with that Greg? > > > > As I think this is the first time that I've had this problem for a DRM > > submission, I don't think it's a big issue yet at all, so whatever you > > are doing today is fine. > > > > I do think that the number of patches submitted for stable for > > drm-related issues feels very very low given the rate of change and > > number of overall patches you all submit to the kernel, so if anything, > > you all should be increasing the number of times you tag stuff for > > stable, not reducing it :) > > Ok, sounds like we should encourage people to use the Fixes: tag and > auto-cc tooling more, not less. > > I also crunched some quick numbers: > commits with cc: stable in drm/amd: 2.6% > ... in drm/i915: 2.5% > ... drm overall: 2.3% > drivers/ overall: 3.1% > > So from a quick look no big outliers at least, maybe not quite enough > cc: stable from smaller drivers (i915+amd is about 60% of everything > in drm). This is for the past year. Compared to drivers/ overall a bit > lower, but not drastically so. At least if I didn't screw up my > scripting. Seems about right, so on those averages, you have missed about 40-50 patches that should have been cc:ed stable. However, you are comparing yourself against stuff like drivers/net/ which shouldn't have cc: stable for most stuff (as per the networking workflow), and other subsystems that seem to never want to cc: stable for various reasons (offenders not mentioned to be nice...) So let's bump that number up a bit, maybe you are missing 100 patches this past year that should have been backported? Feels like you all could tag more, even if the number is only 40-50 :) Oh wait, are you sure you don't count the horrid "double commits" where you backport something from your development branch to your "for linus" branch, and have cc: stable on both, so that during the -rc1 merge window I see a ton of commits that are already in the tree? That would inflate your numbers a lot more so your real percentages might be a lot lower... fun with math. greg k-h _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7278EC433E0 for ; Sat, 8 Aug 2020 11:29:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4FF3C2224D for ; Sat, 8 Aug 2020 11:29:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596886157; bh=vBFMhdAEamx/FNEl4l+v1WdLPZvkH2+eLo10uDinHqg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=e58JmbNAZs79eIBJXxxSFiPbdPnrsEq4ueQxTrzOj8MCkv05HBn+KlQXCh8eE94vI tagBfAVg3aP4PJ43qJfzynWUdg4grr7oLnSO1FWx3VnXaZ1ooRm73iEDOstrRE1+lz x/hb1hv539IjAvbhXW+lvMYEhNyj5jrfndSqElb0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726190AbgHHL25 (ORCPT ); Sat, 8 Aug 2020 07:28:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:41296 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726076AbgHHL24 (ORCPT ); Sat, 8 Aug 2020 07:28:56 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BF5BD221E5; Sat, 8 Aug 2020 11:28:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596886135; bh=vBFMhdAEamx/FNEl4l+v1WdLPZvkH2+eLo10uDinHqg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Ue2UD2xWyI1T6gnQ/OY0ZX3oh8RfImSbhbHzKASzdDO/Weq3v/FUFSeWJHskqyoTv 2hZ+k/CmDVj9NBVI/cEjmMB8FlTIOWThqmcerd6ksiGVBjBdhFd7n8bNENq/gvCBH7 vOa0vtQpd/5OHwJqEUKFWyiTd/2064kSZSXw6XBU= Date: Sat, 8 Aug 2020 13:29:08 +0200 From: Greg KH To: Daniel Vetter Cc: Thomas Zimmermann , dri-devel , Dave Airlie , Alex Deucher , armijn@tjaldur.nl, Emil Velikov , Gerd Hoffmann , Krzysztof Kozlowski , Noralf =?iso-8859-1?Q?Tr=F8nnes?= , Sam Ravnborg , stable , Thomas Gleixner Subject: Re: WTF: patch "[PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header" was seriously submitted to be applied to the 5.8-stable tree? Message-ID: <20200808112908.GA3063898@kroah.com> References: <159680700523135@kroah.com> <20200808102512.GA3039253@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Sat, Aug 08, 2020 at 01:02:34PM +0200, Daniel Vetter wrote: > On Sat, Aug 8, 2020 at 12:24 PM Greg KH wrote: > > > > On Sat, Aug 08, 2020 at 11:13:54AM +0200, Daniel Vetter wrote: > > > On Fri, Aug 7, 2020 at 3:54 PM Thomas Zimmermann wrote: > > > > > > > > Hi > > > > > > > > Am 07.08.20 um 15:30 schrieb gregkh@linuxfoundation.org: > > > > > The patch below was submitted to be applied to the 5.8-stable tree. > > > > > > > > > > I fail to see how this patch meets the stable kernel rules as found at > > > > > Documentation/process/stable-kernel-rules.rst. > > > > > > > > > > I could be totally wrong, and if so, please respond to > > > > > and let me know why this patch should be > > > > > applied. Otherwise, it is now dropped from my patch queues, never to be > > > > > seen again. > > > > > > > > Sorry for the noise. There's no reason this should go into stable. > > > > > > We have a little script in our maintainer toolbox for bugfixes, which > > > generates the Fixes: line, adds everyone from the original commit to > > > the cc: list and also adds Cc: stable if that sha1 the patch fixes is > > > in a release already. > > > > > > I guess we trained people a bit too much on using Fixes: tags like > > > that with the tooling, since they often do that for checkpatch stuff > > > and spelling fixes like this here too. I think the autoselect bot also > > > loves Fixes: tags a bit too much for its own good. > > > > > > Not sure what to do, since telling people to "please sprinkle less > > > Fixes: tags" doesn't sound great either. I also don't want to tell > > > people to use the maintainer toolbox less, the autogenerated cc: list > > > is generally the right thing to do. Maybe best if the stable team > > > catches the obvious ones before adding them to the stable queue, if > > > you're ok with that Greg? > > > > As I think this is the first time that I've had this problem for a DRM > > submission, I don't think it's a big issue yet at all, so whatever you > > are doing today is fine. > > > > I do think that the number of patches submitted for stable for > > drm-related issues feels very very low given the rate of change and > > number of overall patches you all submit to the kernel, so if anything, > > you all should be increasing the number of times you tag stuff for > > stable, not reducing it :) > > Ok, sounds like we should encourage people to use the Fixes: tag and > auto-cc tooling more, not less. > > I also crunched some quick numbers: > commits with cc: stable in drm/amd: 2.6% > ... in drm/i915: 2.5% > ... drm overall: 2.3% > drivers/ overall: 3.1% > > So from a quick look no big outliers at least, maybe not quite enough > cc: stable from smaller drivers (i915+amd is about 60% of everything > in drm). This is for the past year. Compared to drivers/ overall a bit > lower, but not drastically so. At least if I didn't screw up my > scripting. Seems about right, so on those averages, you have missed about 40-50 patches that should have been cc:ed stable. However, you are comparing yourself against stuff like drivers/net/ which shouldn't have cc: stable for most stuff (as per the networking workflow), and other subsystems that seem to never want to cc: stable for various reasons (offenders not mentioned to be nice...) So let's bump that number up a bit, maybe you are missing 100 patches this past year that should have been backported? Feels like you all could tag more, even if the number is only 40-50 :) Oh wait, are you sure you don't count the horrid "double commits" where you backport something from your development branch to your "for linus" branch, and have cc: stable on both, so that during the -rc1 merge window I see a ton of commits that are already in the tree? That would inflate your numbers a lot more so your real percentages might be a lot lower... fun with math. greg k-h