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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 19326C64EBC for ; Mon, 23 Nov 2020 14:20:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D6C022075A for ; Mon, 23 Nov 2020 14:20:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="b0LkeT2q" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730804AbgKWOUL (ORCPT ); Mon, 23 Nov 2020 09:20:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388810AbgKWOUI (ORCPT ); Mon, 23 Nov 2020 09:20:08 -0500 Received: from mail-yb1-xb43.google.com (mail-yb1-xb43.google.com [IPv6:2607:f8b0:4864:20::b43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8DCBAC0613CF; Mon, 23 Nov 2020 06:20:06 -0800 (PST) Received: by mail-yb1-xb43.google.com with SMTP id t33so16099316ybd.0; Mon, 23 Nov 2020 06:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=b0LkeT2q71Z3peIccxL7MkU5QadaCN3igdEC89IE4ykmdOxIlhuoo/0+H7pQCoNmlh 0UX19Z7soasUpz2fDZHX56luUWrH4GLKAJ9K28HwPu9km7qlcvasqfBffaQW+LtXvh6a fVP4J8wQFxbi1QWFB10Wsq9dLONxRShLcqQtcaktrZCy3tSRV5R4FOw2MSdgwNuCxNwd cKQMyE/jYgmlc9Qm972BZKz9xJaasT5iW6gpZgai8YpCh1sxJNgZFzlfCpv21Fvd7rwb akOsznbnFT4mJT95mXFDUPnplTdAJirWAcm8YfzHFRAfOGn9Vk91PuRcq7JipLelDPMB VWgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=k/qgZ8Z9bBqeNograULAsVmY6QgH/o27YDc4TQqwadJEFPSHfj8njq8ybzc5p5uAqz G2SF1GHjXgxVX+FODMOQfjlRZXXNW8F8Ux14RKIUmWQY2couN16YR3yqVIzbwT4iX+yY VYevTNouvCvLvx1xngkvK6RPKneGbHmGKG5FWBekf4NZ/3kPDSYqCl0zGT3EJ0yk0X4t kU+csohpniyEyWF3yBeZ4aH/Tq8NjSKFDNPVh4gegMfVdeoJsrqFPE3o5GJQHSG5qjFd /s6X6u/SLjhTMvHx9dFj3eBhExXvELYjltJz7wnCgTa8WRq49qIZaylj2t5HkrN/zQMT LOBg== X-Gm-Message-State: AOAM533+WIFD/5i1qM3ecRgslbKC6w7KewwGOZRW9A2m2jL8dzVHgZRd FqTd3sI8v3im//r2zntxY7nbBjfQQlZgP2y43RA= X-Google-Smtp-Source: ABdhPJyiJqjBIpEzWlk5pyqpoGG3+KpoWdKnlyza2YA6ODhXnRhATytwh5Bq+iGOzNqc5gs+zuqHC8iB1cjfDTXU/ik= X-Received: by 2002:a25:bcc7:: with SMTP id l7mr32380985ybm.115.1606141205830; Mon, 23 Nov 2020 06:20:05 -0800 (PST) MIME-Version: 1.0 References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> In-Reply-To: <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> From: Miguel Ojeda Date: Mon, 23 Nov 2020 15:19:55 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: James Bottomley Cc: Kees Cook , Jakub Kicinski , "Gustavo A. R. Silva" , linux-kernel , alsa-devel@alsa-project.org, amd-gfx@lists.freedesktop.org, bridge@lists.linux-foundation.org, ceph-devel@vger.kernel.org, cluster-devel@redhat.com, coreteam@netfilter.org, devel@driverdev.osuosl.org, dm-devel@redhat.com, drbd-dev@lists.linbit.com, dri-devel@lists.freedesktop.org, GR-everest-linux-l2@marvell.com, GR-Linux-NIC-Dev@marvell.com, intel-gfx@lists.freedesktop.org, intel-wired-lan@lists.osuosl.org, keyrings@vger.kernel.org, linux1394-devel@lists.sourceforge.net, linux-acpi@vger.kernel.org, linux-afs@lists.infradead.org, Linux ARM , linux-arm-msm@vger.kernel.org, linux-atm-general@lists.sourceforge.net, linux-block@vger.kernel.org, linux-can@vger.kernel.org, linux-cifs@vger.kernel.org, Linux Crypto Mailing List , linux-decnet-user@lists.sourceforge.net, Ext4 Developers List , linux-fbdev@vger.kernel.org, linux-geode@lists.infradead.org, linux-gpio@vger.kernel.org, linux-hams@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-i3c@lists.infradead.org, linux-ide@vger.kernel.org, linux-iio@vger.kernel.org, linux-input , linux-integrity@vger.kernel.org, linux-mediatek@lists.infradead.org, Linux Media Mailing List , linux-mmc@vger.kernel.org, Linux-MM , linux-mtd@lists.infradead.org, linux-nfs@vger.kernel.org, linux-rdma@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org, linux-security-module@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-usb@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-wireless , Network Development , netfilter-devel@vger.kernel.org, nouveau@lists.freedesktop.org, op-tee@lists.trustedfirmware.org, oss-drivers@netronome.com, patches@opensource.cirrus.com, rds-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org, samba-technical@lists.samba.org, selinux@vger.kernel.org, target-devel@vger.kernel.org, tipc-discussion@lists.sourceforge.net, usb-storage@lists.one-eyed-alien.net, virtualization@lists.linux-foundation.org, wcn36xx@lists.infradead.org, "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , xen-devel@lists.xenproject.org, linux-hardening@vger.kernel.org, Nick Desaulniers , Nathan Chancellor , Miguel Ojeda , Joe Perches Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Sun, Nov 22, 2020 at 11:36 PM James Bottomley wrote: > > Well, it seems to be three years of someone's time plus the maintainer > review time and series disruption of nearly a thousand patches. Let's > be conservative and assume the producer worked about 30% on the series > and it takes about 5-10 minutes per patch to review, merge and for > others to rework existing series. So let's say it's cost a person year > of a relatively junior engineer producing the patches and say 100h of > review and application time. The latter is likely the big ticket item > because it's what we have in least supply in the kernel (even though > it's 20x vs the producer time). How are you arriving at such numbers? It is a total of ~200 trivial lines. > It's not about the risk of the changes it's about the cost of > implementing them. Even if you discount the producer time (which > someone gets to pay for, and if I were the engineering manager, I'd be > unhappy about), the review/merge/rework time is pretty significant in > exchange for six minor bug fixes. Fine, when a new compiler warning > comes along it's certainly reasonable to see if we can benefit from it > and the fact that the compiler people think it's worthwhile is enough > evidence to assume this initially. But at some point you have to ask > whether that assumption is supported by the evidence we've accumulated > over the time we've been using it. And if the evidence doesn't support > it perhaps it is time to stop the experiment. Maintainers routinely review 1-line trivial patches, not to mention internal API changes, etc. If some company does not want to pay for that, that's fine, but they don't get to be maintainers and claim `Supported`. Cheers, Miguel 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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 7A718C2D0E4 for ; Mon, 23 Nov 2020 14:20:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C14F120758 for ; Mon, 23 Nov 2020 14:20:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="b0LkeT2q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C14F120758 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2C3806B009C; Mon, 23 Nov 2020 09:20:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 273096B009D; Mon, 23 Nov 2020 09:20:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C7376B009E; Mon, 23 Nov 2020 09:20:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0178.hostedemail.com [216.40.44.178]) by kanga.kvack.org (Postfix) with ESMTP id D34426B009C for ; Mon, 23 Nov 2020 09:20:07 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 73F12181AEF1D for ; Mon, 23 Nov 2020 14:20:07 +0000 (UTC) X-FDA: 77515892454.20.help55_3112bd927366 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id 2F7E5180C07A3 for ; Mon, 23 Nov 2020 14:20:07 +0000 (UTC) X-HE-Tag: help55_3112bd927366 X-Filterd-Recvd-Size: 7567 Received: from mail-yb1-f195.google.com (mail-yb1-f195.google.com [209.85.219.195]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Mon, 23 Nov 2020 14:20:06 +0000 (UTC) Received: by mail-yb1-f195.google.com with SMTP id e81so14496919ybc.1 for ; Mon, 23 Nov 2020 06:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=b0LkeT2q71Z3peIccxL7MkU5QadaCN3igdEC89IE4ykmdOxIlhuoo/0+H7pQCoNmlh 0UX19Z7soasUpz2fDZHX56luUWrH4GLKAJ9K28HwPu9km7qlcvasqfBffaQW+LtXvh6a fVP4J8wQFxbi1QWFB10Wsq9dLONxRShLcqQtcaktrZCy3tSRV5R4FOw2MSdgwNuCxNwd cKQMyE/jYgmlc9Qm972BZKz9xJaasT5iW6gpZgai8YpCh1sxJNgZFzlfCpv21Fvd7rwb akOsznbnFT4mJT95mXFDUPnplTdAJirWAcm8YfzHFRAfOGn9Vk91PuRcq7JipLelDPMB VWgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=tZXg5sMy1niN72mRTGD6ABfq87RPrknTF9d07ICClQda7q28XS8Pwtbz26jyEXn6SP gGFotLFxQsCRg8HmYNj7RC4OEcWPHLZ8dLNKX5fyigR+KAaK58uIb+lYHrIIXylOc34T ySz/r0bnSAtL6OWycDpJEkMo8Q+6zJT5SmqPyGs14Dgw1+cLTnhvuJFanSqREScBVm8g KGDCCXXI4RobRNocTW8m/rxk3E5RMgTvSzEoFk4e+ftaD0E7D/y7S5R58rnHKUKDKowY SGyTsE1SJqk+FxbOA3rQdK2te+2RLh32/K3Zku0CIIpGUecWrrnUGxz5aU/qP+pfKXLW u/RQ== X-Gm-Message-State: AOAM532X6PUThR9KmqnOJk1KvDgItugP52OJTRxNJ+wEXHMGPFAbQH2F w/XYXho9/nuYp1Y3GBAmI+EEhICKvkojnZN1qB8= X-Google-Smtp-Source: ABdhPJyiJqjBIpEzWlk5pyqpoGG3+KpoWdKnlyza2YA6ODhXnRhATytwh5Bq+iGOzNqc5gs+zuqHC8iB1cjfDTXU/ik= X-Received: by 2002:a25:bcc7:: with SMTP id l7mr32380985ybm.115.1606141205830; Mon, 23 Nov 2020 06:20:05 -0800 (PST) MIME-Version: 1.0 References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> In-Reply-To: <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> From: Miguel Ojeda Date: Mon, 23 Nov 2020 15:19:55 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: James Bottomley Cc: Kees Cook , Jakub Kicinski , "Gustavo A. R. Silva" , linux-kernel , alsa-devel@alsa-project.org, amd-gfx@lists.freedesktop.org, bridge@lists.linux-foundation.org, ceph-devel@vger.kernel.org, cluster-devel@redhat.com, coreteam@netfilter.org, devel@driverdev.osuosl.org, dm-devel@redhat.com, drbd-dev@lists.linbit.com, dri-devel@lists.freedesktop.org, GR-everest-linux-l2@marvell.com, GR-Linux-NIC-Dev@marvell.com, intel-gfx@lists.freedesktop.org, intel-wired-lan@lists.osuosl.org, keyrings@vger.kernel.org, linux1394-devel@lists.sourceforge.net, linux-acpi@vger.kernel.org, linux-afs@lists.infradead.org, Linux ARM , linux-arm-msm@vger.kernel.org, linux-atm-general@lists.sourceforge.net, linux-block@vger.kernel.org, linux-can@vger.kernel.org, linux-cifs@vger.kernel.org, Linux Crypto Mailing List , linux-decnet-user@lists.sourceforge.net, Ext4 Developers List , linux-fbdev@vger.kernel.org, linux-geode@lists.infradead.org, linux-gpio@vger.kernel.org, linux-hams@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-i3c@lists.infradead.org, linux-ide@vger.kernel.org, linux-iio@vger.kernel.org, linux-input , linux-integrity@vger.kernel.org, linux-mediatek@lists.infradead.org, Linux Media Mailing List , linux-mmc@vger.kernel.org, Linux-MM , linux-mtd@lists.infradead.org, linux-nfs@vger.kernel.org, linux-rdma@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org, linux-security-module@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-usb@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-wireless , Network Development , netfilter-devel@vger.kernel.org, nouveau@lists.freedesktop.org, op-tee@lists.trustedfirmware.org, oss-drivers@netronome.com, patches@opensource.cirrus.com, rds-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org, samba-technical@lists.samba.org, selinux@vger.kernel.org, target-devel@vger.kernel.org, tipc-discussion@lists.sourceforge.net, usb-storage@lists.one-eyed-alien.net, virtualization@lists.linux-foundation.org, wcn36xx@lists.infradead.org, "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , xen-devel@lists.xenproject.org, linux-hardening@vger.kernel.org, Nick Desaulniers , Nathan Chancellor , Miguel Ojeda , Joe Perches Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, Nov 22, 2020 at 11:36 PM James Bottomley wrote: > > Well, it seems to be three years of someone's time plus the maintainer > review time and series disruption of nearly a thousand patches. Let's > be conservative and assume the producer worked about 30% on the series > and it takes about 5-10 minutes per patch to review, merge and for > others to rework existing series. So let's say it's cost a person year > of a relatively junior engineer producing the patches and say 100h of > review and application time. The latter is likely the big ticket item > because it's what we have in least supply in the kernel (even though > it's 20x vs the producer time). How are you arriving at such numbers? It is a total of ~200 trivial lines. > It's not about the risk of the changes it's about the cost of > implementing them. Even if you discount the producer time (which > someone gets to pay for, and if I were the engineering manager, I'd be > unhappy about), the review/merge/rework time is pretty significant in > exchange for six minor bug fixes. Fine, when a new compiler warning > comes along it's certainly reasonable to see if we can benefit from it > and the fact that the compiler people think it's worthwhile is enough > evidence to assume this initially. But at some point you have to ask > whether that assumption is supported by the evidence we've accumulated > over the time we've been using it. And if the evidence doesn't support > it perhaps it is time to stop the experiment. Maintainers routinely review 1-line trivial patches, not to mention internal API changes, etc. If some company does not want to pay for that, that's fine, but they don't get to be maintainers and claim `Supported`. Cheers, Miguel 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=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 8E360C388F9 for ; Mon, 23 Nov 2020 14:20:11 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (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 2031120782 for ; Mon, 23 Nov 2020 14:20:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="b0LkeT2q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2031120782 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=driverdev-devel-bounces@linuxdriverproject.org Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 89C7D85EF0; Mon, 23 Nov 2020 14:20:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R80ygc1mfCh4; Mon, 23 Nov 2020 14:20:09 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by fraxinus.osuosl.org (Postfix) with ESMTP id D4DCA85F31; Mon, 23 Nov 2020 14:20:09 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by ash.osuosl.org (Postfix) with ESMTP id 878831BF980 for ; Mon, 23 Nov 2020 14:20:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 8361585EFB for ; Mon, 23 Nov 2020 14:20:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oh-y6V6Kjnc for ; Mon, 23 Nov 2020 14:20:06 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-yb1-f195.google.com (mail-yb1-f195.google.com [209.85.219.195]) by fraxinus.osuosl.org (Postfix) with ESMTPS id A01D185EF0 for ; Mon, 23 Nov 2020 14:20:06 +0000 (UTC) Received: by mail-yb1-f195.google.com with SMTP id w5so16043947ybj.11 for ; Mon, 23 Nov 2020 06:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=b0LkeT2q71Z3peIccxL7MkU5QadaCN3igdEC89IE4ykmdOxIlhuoo/0+H7pQCoNmlh 0UX19Z7soasUpz2fDZHX56luUWrH4GLKAJ9K28HwPu9km7qlcvasqfBffaQW+LtXvh6a fVP4J8wQFxbi1QWFB10Wsq9dLONxRShLcqQtcaktrZCy3tSRV5R4FOw2MSdgwNuCxNwd cKQMyE/jYgmlc9Qm972BZKz9xJaasT5iW6gpZgai8YpCh1sxJNgZFzlfCpv21Fvd7rwb akOsznbnFT4mJT95mXFDUPnplTdAJirWAcm8YfzHFRAfOGn9Vk91PuRcq7JipLelDPMB VWgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=LtIUA8RxXgEu+muPNXWuT7sjwvDtCFyEBk1HKtOh7pSRmJPCGSFwuE65byuLu36lRx VzcFh6JhjrEUhuk5oAqqAnQhT1xD+nv8SXsM1umA3/+O895Qxqr97OKYIhTM0vhnxrZ4 ZPBScImDa4Yvx1iZpj0WIL/cFtaU56MUjWG9tCwfKNO059E2BvDN8tP7D+1gVZOW/KFK qsxCCOVXqxML5fTuqFJVLg4s9ykjV23NR4uusNrtsqkIHKGIPBx504eIERLbXvusyBG6 4M//ntrkw7Z+LmftE7jrauOzBb5RC4GfNx25KpFwFEMW5b2d/ds/VhYgUUs0bMzhLt61 R6bg== X-Gm-Message-State: AOAM533/X9tPt+tljdSbN1WIb570yyoSmLnPfEgpUjlSdy71rPfB5B4M RuZnDpOpRNfWMChoOqT+QHvKIvVIt6V5Mf8LRxQ= X-Google-Smtp-Source: ABdhPJyiJqjBIpEzWlk5pyqpoGG3+KpoWdKnlyza2YA6ODhXnRhATytwh5Bq+iGOzNqc5gs+zuqHC8iB1cjfDTXU/ik= X-Received: by 2002:a25:bcc7:: with SMTP id l7mr32380985ybm.115.1606141205830; Mon, 23 Nov 2020 06:20:05 -0800 (PST) MIME-Version: 1.0 References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> In-Reply-To: <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> From: Miguel Ojeda Date: Mon, 23 Nov 2020 15:19:55 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: James Bottomley X-BeenThere: driverdev-devel@linuxdriverproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Driver Project Developer List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , Nathan Chancellor , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, target-devel@vger.kernel.org, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" On Sun, Nov 22, 2020 at 11:36 PM James Bottomley wrote: > > Well, it seems to be three years of someone's time plus the maintainer > review time and series disruption of nearly a thousand patches. Let's > be conservative and assume the producer worked about 30% on the series > and it takes about 5-10 minutes per patch to review, merge and for > others to rework existing series. So let's say it's cost a person year > of a relatively junior engineer producing the patches and say 100h of > review and application time. The latter is likely the big ticket item > because it's what we have in least supply in the kernel (even though > it's 20x vs the producer time). How are you arriving at such numbers? It is a total of ~200 trivial lines. > It's not about the risk of the changes it's about the cost of > implementing them. Even if you discount the producer time (which > someone gets to pay for, and if I were the engineering manager, I'd be > unhappy about), the review/merge/rework time is pretty significant in > exchange for six minor bug fixes. Fine, when a new compiler warning > comes along it's certainly reasonable to see if we can benefit from it > and the fact that the compiler people think it's worthwhile is enough > evidence to assume this initially. But at some point you have to ask > whether that assumption is supported by the evidence we've accumulated > over the time we've been using it. And if the evidence doesn't support > it perhaps it is time to stop the experiment. Maintainers routinely review 1-line trivial patches, not to mention internal API changes, etc. If some company does not want to pay for that, that's fine, but they don't get to be maintainers and claim `Supported`. Cheers, Miguel _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-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=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 72D86C2D0E4 for ; Tue, 24 Nov 2020 17:13:58 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (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 9FDEE206E5 for ; Tue, 24 Nov 2020 17:13:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="pUzS96sP"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="b0LkeT2q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9FDEE206E5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 0D39017D7; Tue, 24 Nov 2020 18:13:06 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 0D39017D7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1606238036; bh=hpzmbQO3ukpaSeFKIRE1jh1hQHTalBalrnavSV3mrW4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=pUzS96sP6krKIwF9t/qb/dQuygDs+aFWAsX4r8dg36NGuYe5xQVG/5zp0qPj8qXrg Q3BaIeH2m0OKtdmGbiQPoruMsoRCLWiwXIi3Je96hrpfSDf6vdJWkUFOyOaNirU2Ka p64ekf2BURmQnvQdDcyDTCBLzlkc5ZFGcVmVf06M= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id C4AD3F805EC; Tue, 24 Nov 2020 17:58:45 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id A63BFF80128; Mon, 23 Nov 2020 15:20:16 +0100 (CET) Received: from mail-yb1-xb42.google.com (mail-yb1-xb42.google.com [IPv6:2607:f8b0:4864:20::b42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 8FF41F80128 for ; Mon, 23 Nov 2020 15:20:08 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 8FF41F80128 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="b0LkeT2q" Received: by mail-yb1-xb42.google.com with SMTP id e81so14496918ybc.1 for ; Mon, 23 Nov 2020 06:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=b0LkeT2q71Z3peIccxL7MkU5QadaCN3igdEC89IE4ykmdOxIlhuoo/0+H7pQCoNmlh 0UX19Z7soasUpz2fDZHX56luUWrH4GLKAJ9K28HwPu9km7qlcvasqfBffaQW+LtXvh6a fVP4J8wQFxbi1QWFB10Wsq9dLONxRShLcqQtcaktrZCy3tSRV5R4FOw2MSdgwNuCxNwd cKQMyE/jYgmlc9Qm972BZKz9xJaasT5iW6gpZgai8YpCh1sxJNgZFzlfCpv21Fvd7rwb akOsznbnFT4mJT95mXFDUPnplTdAJirWAcm8YfzHFRAfOGn9Vk91PuRcq7JipLelDPMB VWgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=Oed8zGwdhP0d9WWZ+7yPxG00PkZw2CXHjrKfXkCXalMJ63JG5C/lK6SQJc9C6Gtd/h i4gdMCPK9OGiVj6FP0XHAgrlXOYaRLMwvgca9bgYsjncl34n728yJvE/w/nL1FgHzdRQ 92d+UCtqGrGtp9uSUrU4flNjuTBfw8+bTDt79aUqwV/A3IjnOW/+YFa3X1kNHKlRoRw2 ROCFpkpUwLQ0uw36EAPCfI12XoqD7bo6y0Pf1TaMeBmueHKNSEFlkjfcb3tYluTTwjX7 AnttBIbcr4zMawjXk7jV6RHn+pnyWYgvf7buHlvZb5X8jOoOPuG+3eh8wsV/jF9AjkFm fieA== X-Gm-Message-State: AOAM532sC2km1Nb7+/54ttScp6Lqc9rSGOqT73szUKHhagcIhMsaJsQC IbSxJ5W53kwLPk5sS5bCCUYeJoPCbmh0kjKfF4Y= X-Google-Smtp-Source: ABdhPJyiJqjBIpEzWlk5pyqpoGG3+KpoWdKnlyza2YA6ODhXnRhATytwh5Bq+iGOzNqc5gs+zuqHC8iB1cjfDTXU/ik= X-Received: by 2002:a25:bcc7:: with SMTP id l7mr32380985ybm.115.1606141205830; Mon, 23 Nov 2020 06:20:05 -0800 (PST) MIME-Version: 1.0 References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> In-Reply-To: <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> From: Miguel Ojeda Date: Mon, 23 Nov 2020 15:19:55 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: James Bottomley Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Tue, 24 Nov 2020 17:58:08 +0100 Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , Nathan Chancellor , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, target-devel@vger.kernel.org, linux-hardening@vger.kernel.org X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Sun, Nov 22, 2020 at 11:36 PM James Bottomley wrote: > > Well, it seems to be three years of someone's time plus the maintainer > review time and series disruption of nearly a thousand patches. Let's > be conservative and assume the producer worked about 30% on the series > and it takes about 5-10 minutes per patch to review, merge and for > others to rework existing series. So let's say it's cost a person year > of a relatively junior engineer producing the patches and say 100h of > review and application time. The latter is likely the big ticket item > because it's what we have in least supply in the kernel (even though > it's 20x vs the producer time). How are you arriving at such numbers? It is a total of ~200 trivial lines. > It's not about the risk of the changes it's about the cost of > implementing them. Even if you discount the producer time (which > someone gets to pay for, and if I were the engineering manager, I'd be > unhappy about), the review/merge/rework time is pretty significant in > exchange for six minor bug fixes. Fine, when a new compiler warning > comes along it's certainly reasonable to see if we can benefit from it > and the fact that the compiler people think it's worthwhile is enough > evidence to assume this initially. But at some point you have to ask > whether that assumption is supported by the evidence we've accumulated > over the time we've been using it. And if the evidence doesn't support > it perhaps it is time to stop the experiment. Maintainers routinely review 1-line trivial patches, not to mention internal API changes, etc. If some company does not want to pay for that, that's fine, but they don't get to be maintainers and claim `Supported`. Cheers, Miguel 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=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 E3FB7C64E69 for ; Mon, 23 Nov 2020 14:20:48 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 68A0020782 for ; Mon, 23 Nov 2020 14:20:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="syzRdsq3"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="b0LkeT2q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 68A0020782 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=4qoSIqw5DFUlJ2E/nbiS6j/oWDU5JCDIGI6ND9ZIDns=; b=syzRdsq3IeDF/B+l6/roP0Bnt fMppUC0aMm8D5B7ukH/HSCSZ3V/1tjQBdidHG0pkVV62jk7m9Aq3fn7C5Q/++tFYJ4OZiOfLcfiEd efinbtT1L+r1wui/KP+e2WQ6n3Rmre9jeErKiwuaHPVnrcei9SpoPdwbOs1HNLICBO3kQIf/DFos6 GDmri/Idfk3MlyI5PzdeZa0iQ+woGbm8lH4+shJxk/oPRoftekvM2ruAjXntnpwN1GmNKm4TKXQII 8qeGKEq2XMRB87hjpLt8NxtFAryUyFObJiSwZECV6JBZazwxEYeu7or7HoweB3H49UD4aXJtuUS2Q D/IVye4Zw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khChU-000541-PC; Mon, 23 Nov 2020 14:20:16 +0000 Received: from mail-yb1-xb41.google.com ([2607:f8b0:4864:20::b41]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1khChM-0004zf-Ca; Mon, 23 Nov 2020 14:20:09 +0000 Received: by mail-yb1-xb41.google.com with SMTP id g15so16066752ybq.6; Mon, 23 Nov 2020 06:20:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=b0LkeT2q71Z3peIccxL7MkU5QadaCN3igdEC89IE4ykmdOxIlhuoo/0+H7pQCoNmlh 0UX19Z7soasUpz2fDZHX56luUWrH4GLKAJ9K28HwPu9km7qlcvasqfBffaQW+LtXvh6a fVP4J8wQFxbi1QWFB10Wsq9dLONxRShLcqQtcaktrZCy3tSRV5R4FOw2MSdgwNuCxNwd cKQMyE/jYgmlc9Qm972BZKz9xJaasT5iW6gpZgai8YpCh1sxJNgZFzlfCpv21Fvd7rwb akOsznbnFT4mJT95mXFDUPnplTdAJirWAcm8YfzHFRAfOGn9Vk91PuRcq7JipLelDPMB VWgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=cUwbMOPAkdeYOY+CPd91q7p6JUvB1Qo3s4RliCrVUWhF7ddCJAySI1340v07Dc+szA LoH76R23HGor07AZtZUiV0WQM8g7rkbFXyx/Ozw7nT5hJLxfxJIajEtuIfARmaLUZpt5 ZihWDvmR776trAwbOL8tB+NUwVnfhogqwsL16LKK7efdClmdp3dyf3oeKpjTM/66ahGO wYpytA6HBfx3zh3X15gbRZYNdN0rihry3aywZHbdNOs7HEePmrbpwU7Gr+yhXSsBxHCt yGUuNxo+OGe8CXFm4hmJUM9ZTYshLDXOE6eMbLC+VYfdh9MG8p8J2CwEnXLqjAFqqXiG lZiQ== X-Gm-Message-State: AOAM531nTUrsC3Ah23GFchkQR7GcyHASv51jBRkKzVk9kO2qQC9hKOhV fX6VTP6JTU8dQYJoXZplizFfxaDntrCExt+l4so= X-Google-Smtp-Source: ABdhPJyiJqjBIpEzWlk5pyqpoGG3+KpoWdKnlyza2YA6ODhXnRhATytwh5Bq+iGOzNqc5gs+zuqHC8iB1cjfDTXU/ik= X-Received: by 2002:a25:bcc7:: with SMTP id l7mr32380985ybm.115.1606141205830; Mon, 23 Nov 2020 06:20:05 -0800 (PST) MIME-Version: 1.0 References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> In-Reply-To: <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> From: Miguel Ojeda Date: Mon, 23 Nov 2020 15:19:55 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: James Bottomley X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201123_092008_469436_AA0CA968 X-CRM114-Status: GOOD ( 18.68 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , Nathan Chancellor , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, target-devel@vger.kernel.org, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Sun, Nov 22, 2020 at 11:36 PM James Bottomley wrote: > > Well, it seems to be three years of someone's time plus the maintainer > review time and series disruption of nearly a thousand patches. Let's > be conservative and assume the producer worked about 30% on the series > and it takes about 5-10 minutes per patch to review, merge and for > others to rework existing series. So let's say it's cost a person year > of a relatively junior engineer producing the patches and say 100h of > review and application time. The latter is likely the big ticket item > because it's what we have in least supply in the kernel (even though > it's 20x vs the producer time). How are you arriving at such numbers? It is a total of ~200 trivial lines. > It's not about the risk of the changes it's about the cost of > implementing them. Even if you discount the producer time (which > someone gets to pay for, and if I were the engineering manager, I'd be > unhappy about), the review/merge/rework time is pretty significant in > exchange for six minor bug fixes. Fine, when a new compiler warning > comes along it's certainly reasonable to see if we can benefit from it > and the fact that the compiler people think it's worthwhile is enough > evidence to assume this initially. But at some point you have to ask > whether that assumption is supported by the evidence we've accumulated > over the time we've been using it. And if the evidence doesn't support > it perhaps it is time to stop the experiment. Maintainers routinely review 1-line trivial patches, not to mention internal API changes, etc. If some company does not want to pay for that, that's fine, but they don't get to be maintainers and claim `Supported`. Cheers, Miguel ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ 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=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 C894EC388F9 for ; Mon, 23 Nov 2020 14:20:23 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 59CD22075A for ; Mon, 23 Nov 2020 14:20:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="QvzP95Dc"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="b0LkeT2q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 59CD22075A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=OJBR4wunfKWefkDdr5p7Ab49KQbQm6KzG0PjWNCZk6Y=; b=QvzP95DckyXm3pxL5wap+AfTJ pv6wgojrVdw5WpkEh6sFfTBVIVnU5jTwmU1OZRqggBORmGi2pZMbuuWtHEylyzaxrerBLN4S+oyOW JySkf8GcQHDPpXrc3Lt5mbkpAXoT1lkaEBZHAfZ5fcbYLaETYIcYLvJF0pawv9hDnEKs2dkPNI0CM Gv2swW1DLbyDiZpXZz5NwFXspQ/TVp6bPeGqKawrJKlp601OhoUwLMbsYYI/GhD89b8vatdnKOXpD ZvsLT4O6D7maPKWaJWxAk5/XQBrDHEgHj+qlYy07I81rWabIDidrSeV5x018dQWNfbqXko0iSMloI 1T70jpIyg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khChS-000530-Jw; Mon, 23 Nov 2020 14:20:14 +0000 Received: from mail-yb1-xb41.google.com ([2607:f8b0:4864:20::b41]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1khChM-0004zf-Ca; Mon, 23 Nov 2020 14:20:09 +0000 Received: by mail-yb1-xb41.google.com with SMTP id g15so16066752ybq.6; Mon, 23 Nov 2020 06:20:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=b0LkeT2q71Z3peIccxL7MkU5QadaCN3igdEC89IE4ykmdOxIlhuoo/0+H7pQCoNmlh 0UX19Z7soasUpz2fDZHX56luUWrH4GLKAJ9K28HwPu9km7qlcvasqfBffaQW+LtXvh6a fVP4J8wQFxbi1QWFB10Wsq9dLONxRShLcqQtcaktrZCy3tSRV5R4FOw2MSdgwNuCxNwd cKQMyE/jYgmlc9Qm972BZKz9xJaasT5iW6gpZgai8YpCh1sxJNgZFzlfCpv21Fvd7rwb akOsznbnFT4mJT95mXFDUPnplTdAJirWAcm8YfzHFRAfOGn9Vk91PuRcq7JipLelDPMB VWgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=cUwbMOPAkdeYOY+CPd91q7p6JUvB1Qo3s4RliCrVUWhF7ddCJAySI1340v07Dc+szA LoH76R23HGor07AZtZUiV0WQM8g7rkbFXyx/Ozw7nT5hJLxfxJIajEtuIfARmaLUZpt5 ZihWDvmR776trAwbOL8tB+NUwVnfhogqwsL16LKK7efdClmdp3dyf3oeKpjTM/66ahGO wYpytA6HBfx3zh3X15gbRZYNdN0rihry3aywZHbdNOs7HEePmrbpwU7Gr+yhXSsBxHCt yGUuNxo+OGe8CXFm4hmJUM9ZTYshLDXOE6eMbLC+VYfdh9MG8p8J2CwEnXLqjAFqqXiG lZiQ== X-Gm-Message-State: AOAM531nTUrsC3Ah23GFchkQR7GcyHASv51jBRkKzVk9kO2qQC9hKOhV fX6VTP6JTU8dQYJoXZplizFfxaDntrCExt+l4so= X-Google-Smtp-Source: ABdhPJyiJqjBIpEzWlk5pyqpoGG3+KpoWdKnlyza2YA6ODhXnRhATytwh5Bq+iGOzNqc5gs+zuqHC8iB1cjfDTXU/ik= X-Received: by 2002:a25:bcc7:: with SMTP id l7mr32380985ybm.115.1606141205830; Mon, 23 Nov 2020 06:20:05 -0800 (PST) MIME-Version: 1.0 References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> In-Reply-To: <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> From: Miguel Ojeda Date: Mon, 23 Nov 2020 15:19:55 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: James Bottomley X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201123_092008_469436_AA0CA968 X-CRM114-Status: GOOD ( 18.68 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , Nathan Chancellor , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, target-devel@vger.kernel.org, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Sun, Nov 22, 2020 at 11:36 PM James Bottomley wrote: > > Well, it seems to be three years of someone's time plus the maintainer > review time and series disruption of nearly a thousand patches. Let's > be conservative and assume the producer worked about 30% on the series > and it takes about 5-10 minutes per patch to review, merge and for > others to rework existing series. So let's say it's cost a person year > of a relatively junior engineer producing the patches and say 100h of > review and application time. The latter is likely the big ticket item > because it's what we have in least supply in the kernel (even though > it's 20x vs the producer time). How are you arriving at such numbers? It is a total of ~200 trivial lines. > It's not about the risk of the changes it's about the cost of > implementing them. Even if you discount the producer time (which > someone gets to pay for, and if I were the engineering manager, I'd be > unhappy about), the review/merge/rework time is pretty significant in > exchange for six minor bug fixes. Fine, when a new compiler warning > comes along it's certainly reasonable to see if we can benefit from it > and the fact that the compiler people think it's worthwhile is enough > evidence to assume this initially. But at some point you have to ask > whether that assumption is supported by the evidence we've accumulated > over the time we've been using it. And if the evidence doesn't support > it perhaps it is time to stop the experiment. Maintainers routinely review 1-line trivial patches, not to mention internal API changes, etc. If some company does not want to pay for that, that's fine, but they don't get to be maintainers and claim `Supported`. Cheers, Miguel _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 ECB29C2D0E4 for ; Mon, 23 Nov 2020 14:20:14 +0000 (UTC) Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (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 571DF20781 for ; Mon, 23 Nov 2020 14:20:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="b0LkeT2q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 571DF20781 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=virtualization-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id B8ECD204A4; Mon, 23 Nov 2020 14:20:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1GSykFxA9vp; Mon, 23 Nov 2020 14:20:09 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by silver.osuosl.org (Postfix) with ESMTP id 3ACB020467; Mon, 23 Nov 2020 14:20:09 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 11CD1C163C; Mon, 23 Nov 2020 14:20:09 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 65666C0052; Mon, 23 Nov 2020 14:20:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 5689A85F31; Mon, 23 Nov 2020 14:20:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjVM1yfxCTck; Mon, 23 Nov 2020 14:20:06 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-yb1-f194.google.com (mail-yb1-f194.google.com [209.85.219.194]) by fraxinus.osuosl.org (Postfix) with ESMTPS id A0D9485EFB; Mon, 23 Nov 2020 14:20:06 +0000 (UTC) Received: by mail-yb1-f194.google.com with SMTP id 2so16036807ybc.12; Mon, 23 Nov 2020 06:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=b0LkeT2q71Z3peIccxL7MkU5QadaCN3igdEC89IE4ykmdOxIlhuoo/0+H7pQCoNmlh 0UX19Z7soasUpz2fDZHX56luUWrH4GLKAJ9K28HwPu9km7qlcvasqfBffaQW+LtXvh6a fVP4J8wQFxbi1QWFB10Wsq9dLONxRShLcqQtcaktrZCy3tSRV5R4FOw2MSdgwNuCxNwd cKQMyE/jYgmlc9Qm972BZKz9xJaasT5iW6gpZgai8YpCh1sxJNgZFzlfCpv21Fvd7rwb akOsznbnFT4mJT95mXFDUPnplTdAJirWAcm8YfzHFRAfOGn9Vk91PuRcq7JipLelDPMB VWgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=EIb51uFkJ6rIU2GtwCgPw0LlReSPIuAMShYwBjEehKhayqr8Sqy1w585iqIKDaOg3F g1f7ssLx685JJy44OVeq4LWjRpD6TDEFbd+vF/NKgPKejFK3JZinx9as88X9Ad3k6ruR 7tfg6WWwu1xF/l0G9vlV0OV3qpgIfPJUYXwHMOryGlQrpM47lhKTs+8MYEFVelk6G0xA Q2oXOMB2s7BWSG0x53gilkYGUaTxXzfH92C+DXEdGTVT5SDQZDMjQb7K35auWgLW88Db jwOxw3jszWbP15MaH/W3vrEddDxo2V7G+lBllSN2XBnNyhNzu0tY+KKudCus4tAKyL++ gD+Q== X-Gm-Message-State: AOAM5313Jg6AoU/NUbDMIGAjbFY4/RQFTdz+36HWcwVq32R4BeYmfxsN b8Lc+B6IZP3lB7Fwvuul78RUFrAKkogGb1U8zds= X-Google-Smtp-Source: ABdhPJyiJqjBIpEzWlk5pyqpoGG3+KpoWdKnlyza2YA6ODhXnRhATytwh5Bq+iGOzNqc5gs+zuqHC8iB1cjfDTXU/ik= X-Received: by 2002:a25:bcc7:: with SMTP id l7mr32380985ybm.115.1606141205830; Mon, 23 Nov 2020 06:20:05 -0800 (PST) MIME-Version: 1.0 References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> In-Reply-To: <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> From: Miguel Ojeda Date: Mon, 23 Nov 2020 15:19:55 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: James Bottomley Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , Nathan Chancellor , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, target-devel@vger.kernel.org, linux-hardening@vger.kernel.org X-BeenThere: virtualization@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux virtualization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" On Sun, Nov 22, 2020 at 11:36 PM James Bottomley wrote: > > Well, it seems to be three years of someone's time plus the maintainer > review time and series disruption of nearly a thousand patches. Let's > be conservative and assume the producer worked about 30% on the series > and it takes about 5-10 minutes per patch to review, merge and for > others to rework existing series. So let's say it's cost a person year > of a relatively junior engineer producing the patches and say 100h of > review and application time. The latter is likely the big ticket item > because it's what we have in least supply in the kernel (even though > it's 20x vs the producer time). How are you arriving at such numbers? It is a total of ~200 trivial lines. > It's not about the risk of the changes it's about the cost of > implementing them. Even if you discount the producer time (which > someone gets to pay for, and if I were the engineering manager, I'd be > unhappy about), the review/merge/rework time is pretty significant in > exchange for six minor bug fixes. Fine, when a new compiler warning > comes along it's certainly reasonable to see if we can benefit from it > and the fact that the compiler people think it's worthwhile is enough > evidence to assume this initially. But at some point you have to ask > whether that assumption is supported by the evidence we've accumulated > over the time we've been using it. And if the evidence doesn't support > it perhaps it is time to stop the experiment. Maintainers routinely review 1-line trivial patches, not to mention internal API changes, etc. If some company does not want to pay for that, that's fine, but they don't get to be maintainers and claim `Supported`. Cheers, Miguel _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization 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=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 9CF96C2D0E4 for ; Tue, 24 Nov 2020 08:09:34 +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 3D477206D9 for ; Tue, 24 Nov 2020 08:09:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="b0LkeT2q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3D477206D9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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 4C2576E247; Tue, 24 Nov 2020 08:09:20 +0000 (UTC) Received: from mail-yb1-xb41.google.com (mail-yb1-xb41.google.com [IPv6:2607:f8b0:4864:20::b41]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9B431898F5; Mon, 23 Nov 2020 14:20:06 +0000 (UTC) Received: by mail-yb1-xb41.google.com with SMTP id o144so16071843ybg.7; Mon, 23 Nov 2020 06:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=b0LkeT2q71Z3peIccxL7MkU5QadaCN3igdEC89IE4ykmdOxIlhuoo/0+H7pQCoNmlh 0UX19Z7soasUpz2fDZHX56luUWrH4GLKAJ9K28HwPu9km7qlcvasqfBffaQW+LtXvh6a fVP4J8wQFxbi1QWFB10Wsq9dLONxRShLcqQtcaktrZCy3tSRV5R4FOw2MSdgwNuCxNwd cKQMyE/jYgmlc9Qm972BZKz9xJaasT5iW6gpZgai8YpCh1sxJNgZFzlfCpv21Fvd7rwb akOsznbnFT4mJT95mXFDUPnplTdAJirWAcm8YfzHFRAfOGn9Vk91PuRcq7JipLelDPMB VWgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=sE1S6kNutuoG4Kzc2RDoAPlgPz8wU//qoVGxAR8Jsdb/mUtDezmB1JSRf5rZmvRw+e RDm6bqHm7XnhI8TLeFDeuIJvU+OmBgqDV9ME01hwRXb/Fbb2+JiinJE6MxHRsF82a31G nKpwbvxX7QaTEnMc20KRmdN5l3gyIR15IsbkkzkHAxx/qfvBRqejyIxjfAIGSOSbsSJD MUOZa+kNegPF3oSbv4WQcNLhrc/dLW/6jY0p3yZfKCpF2vKXOPpO8Axzih3xLZd1ym57 F+ZP5OgP9V06QR4md+iKCufTlTO0h/rQ7IK9cEfDaBF+tt9sgoHyQxiTWHtq1EWQ/7WQ X2xA== X-Gm-Message-State: AOAM531LBRVJ4hKo3U5XCegtJUrn9yhO+G6cIY5ByYkKvpA37iWto8Op CN5sk48XmTJE3/d7fVXb5cx04/xzy5R/GURZKXY= X-Google-Smtp-Source: ABdhPJyiJqjBIpEzWlk5pyqpoGG3+KpoWdKnlyza2YA6ODhXnRhATytwh5Bq+iGOzNqc5gs+zuqHC8iB1cjfDTXU/ik= X-Received: by 2002:a25:bcc7:: with SMTP id l7mr32380985ybm.115.1606141205830; Mon, 23 Nov 2020 06:20:05 -0800 (PST) MIME-Version: 1.0 References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> In-Reply-To: <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> From: Miguel Ojeda Date: Mon, 23 Nov 2020 15:19:55 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: James Bottomley X-Mailman-Approved-At: Tue, 24 Nov 2020 08:08:40 +0000 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: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , Nathan Chancellor , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, target-devel@vger.kernel.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-hardening@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Sun, Nov 22, 2020 at 11:36 PM James Bottomley wrote: > > Well, it seems to be three years of someone's time plus the maintainer > review time and series disruption of nearly a thousand patches. Let's > be conservative and assume the producer worked about 30% on the series > and it takes about 5-10 minutes per patch to review, merge and for > others to rework existing series. So let's say it's cost a person year > of a relatively junior engineer producing the patches and say 100h of > review and application time. The latter is likely the big ticket item > because it's what we have in least supply in the kernel (even though > it's 20x vs the producer time). How are you arriving at such numbers? It is a total of ~200 trivial lines. > It's not about the risk of the changes it's about the cost of > implementing them. Even if you discount the producer time (which > someone gets to pay for, and if I were the engineering manager, I'd be > unhappy about), the review/merge/rework time is pretty significant in > exchange for six minor bug fixes. Fine, when a new compiler warning > comes along it's certainly reasonable to see if we can benefit from it > and the fact that the compiler people think it's worthwhile is enough > evidence to assume this initially. But at some point you have to ask > whether that assumption is supported by the evidence we've accumulated > over the time we've been using it. And if the evidence doesn't support > it perhaps it is time to stop the experiment. Maintainers routinely review 1-line trivial patches, not to mention internal API changes, etc. If some company does not want to pay for that, that's fine, but they don't get to be maintainers and claim `Supported`. Cheers, Miguel _______________________________________________ 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=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,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 DB746C2D0E4 for ; Tue, 24 Nov 2020 08:54:19 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 44FA92073C for ; Tue, 24 Nov 2020 08:54:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 44FA92073C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=dm-devel-bounces@redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-404-yRMGVNPKPZC-PqUmYTNRAA-1; Tue, 24 Nov 2020 03:54:16 -0500 X-MC-Unique: yRMGVNPKPZC-PqUmYTNRAA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BB3D59A225; Tue, 24 Nov 2020 08:54:11 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9D1D35C1BD; Tue, 24 Nov 2020 08:54:11 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 6FF321809CA2; Tue, 24 Nov 2020 08:54:11 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 0ANEKEXx003335 for ; Mon, 23 Nov 2020 09:20:14 -0500 Received: by smtp.corp.redhat.com (Postfix) id E6D182166B2E; Mon, 23 Nov 2020 14:20:13 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast06.extmail.prod.ext.rdu2.redhat.com [10.11.55.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E11CF2166B2B for ; Mon, 23 Nov 2020 14:20:10 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C293A1871CCC for ; Mon, 23 Nov 2020 14:20:10 +0000 (UTC) Received: from mail-yb1-f193.google.com (mail-yb1-f193.google.com [209.85.219.193]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-29-8LgImwgoM6-RkhVaxFGv2w-1; Mon, 23 Nov 2020 09:20:06 -0500 X-MC-Unique: 8LgImwgoM6-RkhVaxFGv2w-1 Received: by mail-yb1-f193.google.com with SMTP id k65so16071111ybk.5; Mon, 23 Nov 2020 06:20:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=qdva/cRzzmx5gKFNCRVe84Fsq9RsOHQmzHqrhFm3+ThudTHS0izaKy4g8blyfbIqNp 1cG5FXz1OSdZcmplFdRGLVaMmqw6oOpNxPqno8YeDkTMfkRTxz3qogSseeQH3i8CZ5AC 78d/7qNDxQSdbDMf2HuLlBnWSSOv6VqBocgS4P4jfR7iL5tlw9n/mXBcQ+D2xo9ZRbHy bV4fIBYTXv3lMqgpRFCsKWYjlQ5+Bwwc3nw4eSocvP4m83odFMPfJ/YYx7zwpAT1rS1p e6F8RG29Rob8HBcZNlNNISo3rlwtx2oaJO6mt9SFGeW9X74qkHfe8COQNaXsvNfTp2CP jsJA== X-Gm-Message-State: AOAM533xYP2JZJkxJyADqujrX8H8HCVwduO/OxefP8wyVs+iCsTlup4v OeghijBATns7+TQsKQLwYxJWMsZYB5PpzX/DSPs= X-Google-Smtp-Source: ABdhPJyiJqjBIpEzWlk5pyqpoGG3+KpoWdKnlyza2YA6ODhXnRhATytwh5Bq+iGOzNqc5gs+zuqHC8iB1cjfDTXU/ik= X-Received: by 2002:a25:bcc7:: with SMTP id l7mr32380985ybm.115.1606141205830; Mon, 23 Nov 2020 06:20:05 -0800 (PST) MIME-Version: 1.0 References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> In-Reply-To: <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> From: Miguel Ojeda Date: Mon, 23 Nov 2020 15:19:55 +0100 Message-ID: To: James Bottomley X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-loop: dm-devel@redhat.com X-Mailman-Approved-At: Tue, 24 Nov 2020 03:53:49 -0500 Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, nouveau@lists.freedesktop.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , Nathan Chancellor , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, linux-watchdog@vger.kernel.org, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, drbd-dev@tron.linbit.com, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, target-devel@vger.kernel.org, Linux ARM , linux-hwmon@vger.kernel.org, "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dm-devel-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sun, Nov 22, 2020 at 11:36 PM James Bottomley wrote: > > Well, it seems to be three years of someone's time plus the maintainer > review time and series disruption of nearly a thousand patches. Let's > be conservative and assume the producer worked about 30% on the series > and it takes about 5-10 minutes per patch to review, merge and for > others to rework existing series. So let's say it's cost a person year > of a relatively junior engineer producing the patches and say 100h of > review and application time. The latter is likely the big ticket item > because it's what we have in least supply in the kernel (even though > it's 20x vs the producer time). How are you arriving at such numbers? It is a total of ~200 trivial lines. > It's not about the risk of the changes it's about the cost of > implementing them. Even if you discount the producer time (which > someone gets to pay for, and if I were the engineering manager, I'd be > unhappy about), the review/merge/rework time is pretty significant in > exchange for six minor bug fixes. Fine, when a new compiler warning > comes along it's certainly reasonable to see if we can benefit from it > and the fact that the compiler people think it's worthwhile is enough > evidence to assume this initially. But at some point you have to ask > whether that assumption is supported by the evidence we've accumulated > over the time we've been using it. And if the evidence doesn't support > it perhaps it is time to stop the experiment. Maintainers routinely review 1-line trivial patches, not to mention internal API changes, etc. If some company does not want to pay for that, that's fine, but they don't get to be maintainers and claim `Supported`. Cheers, Miguel -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-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=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 94FE5C2D0E4 for ; Mon, 23 Nov 2020 14:55:04 +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 2C9FC20658 for ; Mon, 23 Nov 2020 14:55:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="b0LkeT2q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C9FC20658 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7340189DB4; Mon, 23 Nov 2020 14:55:03 +0000 (UTC) Received: from mail-yb1-xb41.google.com (mail-yb1-xb41.google.com [IPv6:2607:f8b0:4864:20::b41]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9B431898F5; Mon, 23 Nov 2020 14:20:06 +0000 (UTC) Received: by mail-yb1-xb41.google.com with SMTP id o144so16071843ybg.7; Mon, 23 Nov 2020 06:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=b0LkeT2q71Z3peIccxL7MkU5QadaCN3igdEC89IE4ykmdOxIlhuoo/0+H7pQCoNmlh 0UX19Z7soasUpz2fDZHX56luUWrH4GLKAJ9K28HwPu9km7qlcvasqfBffaQW+LtXvh6a fVP4J8wQFxbi1QWFB10Wsq9dLONxRShLcqQtcaktrZCy3tSRV5R4FOw2MSdgwNuCxNwd cKQMyE/jYgmlc9Qm972BZKz9xJaasT5iW6gpZgai8YpCh1sxJNgZFzlfCpv21Fvd7rwb akOsznbnFT4mJT95mXFDUPnplTdAJirWAcm8YfzHFRAfOGn9Vk91PuRcq7JipLelDPMB VWgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=sE1S6kNutuoG4Kzc2RDoAPlgPz8wU//qoVGxAR8Jsdb/mUtDezmB1JSRf5rZmvRw+e RDm6bqHm7XnhI8TLeFDeuIJvU+OmBgqDV9ME01hwRXb/Fbb2+JiinJE6MxHRsF82a31G nKpwbvxX7QaTEnMc20KRmdN5l3gyIR15IsbkkzkHAxx/qfvBRqejyIxjfAIGSOSbsSJD MUOZa+kNegPF3oSbv4WQcNLhrc/dLW/6jY0p3yZfKCpF2vKXOPpO8Axzih3xLZd1ym57 F+ZP5OgP9V06QR4md+iKCufTlTO0h/rQ7IK9cEfDaBF+tt9sgoHyQxiTWHtq1EWQ/7WQ X2xA== X-Gm-Message-State: AOAM531LBRVJ4hKo3U5XCegtJUrn9yhO+G6cIY5ByYkKvpA37iWto8Op CN5sk48XmTJE3/d7fVXb5cx04/xzy5R/GURZKXY= X-Google-Smtp-Source: ABdhPJyiJqjBIpEzWlk5pyqpoGG3+KpoWdKnlyza2YA6ODhXnRhATytwh5Bq+iGOzNqc5gs+zuqHC8iB1cjfDTXU/ik= X-Received: by 2002:a25:bcc7:: with SMTP id l7mr32380985ybm.115.1606141205830; Mon, 23 Nov 2020 06:20:05 -0800 (PST) MIME-Version: 1.0 References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> In-Reply-To: <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> From: Miguel Ojeda Date: Mon, 23 Nov 2020 15:19:55 +0100 Message-ID: To: James Bottomley X-Mailman-Approved-At: Mon, 23 Nov 2020 14:55:03 +0000 Subject: Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , Nathan Chancellor , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, target-devel@vger.kernel.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-hardening@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Sun, Nov 22, 2020 at 11:36 PM James Bottomley wrote: > > Well, it seems to be three years of someone's time plus the maintainer > review time and series disruption of nearly a thousand patches. Let's > be conservative and assume the producer worked about 30% on the series > and it takes about 5-10 minutes per patch to review, merge and for > others to rework existing series. So let's say it's cost a person year > of a relatively junior engineer producing the patches and say 100h of > review and application time. The latter is likely the big ticket item > because it's what we have in least supply in the kernel (even though > it's 20x vs the producer time). How are you arriving at such numbers? It is a total of ~200 trivial lines. > It's not about the risk of the changes it's about the cost of > implementing them. Even if you discount the producer time (which > someone gets to pay for, and if I were the engineering manager, I'd be > unhappy about), the review/merge/rework time is pretty significant in > exchange for six minor bug fixes. Fine, when a new compiler warning > comes along it's certainly reasonable to see if we can benefit from it > and the fact that the compiler people think it's worthwhile is enough > evidence to assume this initially. But at some point you have to ask > whether that assumption is supported by the evidence we've accumulated > over the time we've been using it. And if the evidence doesn't support > it perhaps it is time to stop the experiment. Maintainers routinely review 1-line trivial patches, not to mention internal API changes, etc. If some company does not want to pay for that, that's fine, but they don't get to be maintainers and claim `Supported`. Cheers, Miguel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx 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=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 B17DAC6379D for ; Mon, 23 Nov 2020 14:20:46 +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 5CEFA20758 for ; Mon, 23 Nov 2020 14:20:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="b0LkeT2q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5CEFA20758 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=amd-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B931589B60; Mon, 23 Nov 2020 14:20:45 +0000 (UTC) Received: from mail-yb1-xb41.google.com (mail-yb1-xb41.google.com [IPv6:2607:f8b0:4864:20::b41]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9B431898F5; Mon, 23 Nov 2020 14:20:06 +0000 (UTC) Received: by mail-yb1-xb41.google.com with SMTP id o144so16071843ybg.7; Mon, 23 Nov 2020 06:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=b0LkeT2q71Z3peIccxL7MkU5QadaCN3igdEC89IE4ykmdOxIlhuoo/0+H7pQCoNmlh 0UX19Z7soasUpz2fDZHX56luUWrH4GLKAJ9K28HwPu9km7qlcvasqfBffaQW+LtXvh6a fVP4J8wQFxbi1QWFB10Wsq9dLONxRShLcqQtcaktrZCy3tSRV5R4FOw2MSdgwNuCxNwd cKQMyE/jYgmlc9Qm972BZKz9xJaasT5iW6gpZgai8YpCh1sxJNgZFzlfCpv21Fvd7rwb akOsznbnFT4mJT95mXFDUPnplTdAJirWAcm8YfzHFRAfOGn9Vk91PuRcq7JipLelDPMB VWgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=sE1S6kNutuoG4Kzc2RDoAPlgPz8wU//qoVGxAR8Jsdb/mUtDezmB1JSRf5rZmvRw+e RDm6bqHm7XnhI8TLeFDeuIJvU+OmBgqDV9ME01hwRXb/Fbb2+JiinJE6MxHRsF82a31G nKpwbvxX7QaTEnMc20KRmdN5l3gyIR15IsbkkzkHAxx/qfvBRqejyIxjfAIGSOSbsSJD MUOZa+kNegPF3oSbv4WQcNLhrc/dLW/6jY0p3yZfKCpF2vKXOPpO8Axzih3xLZd1ym57 F+ZP5OgP9V06QR4md+iKCufTlTO0h/rQ7IK9cEfDaBF+tt9sgoHyQxiTWHtq1EWQ/7WQ X2xA== X-Gm-Message-State: AOAM531LBRVJ4hKo3U5XCegtJUrn9yhO+G6cIY5ByYkKvpA37iWto8Op CN5sk48XmTJE3/d7fVXb5cx04/xzy5R/GURZKXY= X-Google-Smtp-Source: ABdhPJyiJqjBIpEzWlk5pyqpoGG3+KpoWdKnlyza2YA6ODhXnRhATytwh5Bq+iGOzNqc5gs+zuqHC8iB1cjfDTXU/ik= X-Received: by 2002:a25:bcc7:: with SMTP id l7mr32380985ybm.115.1606141205830; Mon, 23 Nov 2020 06:20:05 -0800 (PST) MIME-Version: 1.0 References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> In-Reply-To: <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> From: Miguel Ojeda Date: Mon, 23 Nov 2020 15:19:55 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: James Bottomley X-Mailman-Approved-At: Mon, 23 Nov 2020 14:20:44 +0000 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , Nathan Chancellor , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, target-devel@vger.kernel.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-hardening@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On Sun, Nov 22, 2020 at 11:36 PM James Bottomley wrote: > > Well, it seems to be three years of someone's time plus the maintainer > review time and series disruption of nearly a thousand patches. Let's > be conservative and assume the producer worked about 30% on the series > and it takes about 5-10 minutes per patch to review, merge and for > others to rework existing series. So let's say it's cost a person year > of a relatively junior engineer producing the patches and say 100h of > review and application time. The latter is likely the big ticket item > because it's what we have in least supply in the kernel (even though > it's 20x vs the producer time). How are you arriving at such numbers? It is a total of ~200 trivial lines. > It's not about the risk of the changes it's about the cost of > implementing them. Even if you discount the producer time (which > someone gets to pay for, and if I were the engineering manager, I'd be > unhappy about), the review/merge/rework time is pretty significant in > exchange for six minor bug fixes. Fine, when a new compiler warning > comes along it's certainly reasonable to see if we can benefit from it > and the fact that the compiler people think it's worthwhile is enough > evidence to assume this initially. But at some point you have to ask > whether that assumption is supported by the evidence we've accumulated > over the time we've been using it. And if the evidence doesn't support > it perhaps it is time to stop the experiment. Maintainers routinely review 1-line trivial patches, not to mention internal API changes, etc. If some company does not want to pay for that, that's fine, but they don't get to be maintainers and claim `Supported`. Cheers, Miguel _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx 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=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 7D8DEC56201 for ; Wed, 25 Nov 2020 09:57:21 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 087A92083E for ; Wed, 25 Nov 2020 09:57:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="zImmPm0e"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="b0LkeT2q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 087A92083E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-i3c-bounces+linux-i3c=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=9lgwoyrJrdNFpnuSEopfQgIEaJ73KeWdQ1WaOD+ZM44=; b=zImmPm0emhApp6lGePDRdJhKU d3E/2PeCh/ldTOWKxYT/N1xtpR/xyQ1dcVJhu9abgvCIap6z6dGXaNth88e/ZKQjRSrXti0V84XHT 7tLIZBaGxUw2MXPju9A12ucE+88eql8dSPGjY3bvsZQoDlrUngVsjVC1Bc81qfilwvUbNkybtfAYg 1tgw6rdaasKOjqcf15GJCp7HjdpI3VEmyxyDG5I5XSkh9oWTpZzeqJhXJ5k6lu8rleksktnNdOyvU nR0TgWZQv0IIIODL9Ldn3dd6Zuio7sZ8tvOdrs8VZfDwZgcoEeDFsNJJZ5G+a8IZuqA6Q7zNnwdFj QXyRpbHQg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khrY8-0006Vw-1z; Wed, 25 Nov 2020 09:57:20 +0000 Received: from mail-yb1-xb41.google.com ([2607:f8b0:4864:20::b41]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1khChM-0004zf-Ca; Mon, 23 Nov 2020 14:20:09 +0000 Received: by mail-yb1-xb41.google.com with SMTP id g15so16066752ybq.6; Mon, 23 Nov 2020 06:20:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=b0LkeT2q71Z3peIccxL7MkU5QadaCN3igdEC89IE4ykmdOxIlhuoo/0+H7pQCoNmlh 0UX19Z7soasUpz2fDZHX56luUWrH4GLKAJ9K28HwPu9km7qlcvasqfBffaQW+LtXvh6a fVP4J8wQFxbi1QWFB10Wsq9dLONxRShLcqQtcaktrZCy3tSRV5R4FOw2MSdgwNuCxNwd cKQMyE/jYgmlc9Qm972BZKz9xJaasT5iW6gpZgai8YpCh1sxJNgZFzlfCpv21Fvd7rwb akOsznbnFT4mJT95mXFDUPnplTdAJirWAcm8YfzHFRAfOGn9Vk91PuRcq7JipLelDPMB VWgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=cUwbMOPAkdeYOY+CPd91q7p6JUvB1Qo3s4RliCrVUWhF7ddCJAySI1340v07Dc+szA LoH76R23HGor07AZtZUiV0WQM8g7rkbFXyx/Ozw7nT5hJLxfxJIajEtuIfARmaLUZpt5 ZihWDvmR776trAwbOL8tB+NUwVnfhogqwsL16LKK7efdClmdp3dyf3oeKpjTM/66ahGO wYpytA6HBfx3zh3X15gbRZYNdN0rihry3aywZHbdNOs7HEePmrbpwU7Gr+yhXSsBxHCt yGUuNxo+OGe8CXFm4hmJUM9ZTYshLDXOE6eMbLC+VYfdh9MG8p8J2CwEnXLqjAFqqXiG lZiQ== X-Gm-Message-State: AOAM531nTUrsC3Ah23GFchkQR7GcyHASv51jBRkKzVk9kO2qQC9hKOhV fX6VTP6JTU8dQYJoXZplizFfxaDntrCExt+l4so= X-Google-Smtp-Source: ABdhPJyiJqjBIpEzWlk5pyqpoGG3+KpoWdKnlyza2YA6ODhXnRhATytwh5Bq+iGOzNqc5gs+zuqHC8iB1cjfDTXU/ik= X-Received: by 2002:a25:bcc7:: with SMTP id l7mr32380985ybm.115.1606141205830; Mon, 23 Nov 2020 06:20:05 -0800 (PST) MIME-Version: 1.0 References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> In-Reply-To: <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> From: Miguel Ojeda Date: Mon, 23 Nov 2020 15:19:55 +0100 Message-ID: Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang To: James Bottomley X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201123_092008_469436_AA0CA968 X-CRM114-Status: GOOD ( 18.68 ) X-Mailman-Approved-At: Wed, 25 Nov 2020 04:56:59 -0500 X-BeenThere: linux-i3c@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , Nathan Chancellor , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, target-devel@vger.kernel.org, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-i3c" Errors-To: linux-i3c-bounces+linux-i3c=archiver.kernel.org@lists.infradead.org On Sun, Nov 22, 2020 at 11:36 PM James Bottomley wrote: > > Well, it seems to be three years of someone's time plus the maintainer > review time and series disruption of nearly a thousand patches. Let's > be conservative and assume the producer worked about 30% on the series > and it takes about 5-10 minutes per patch to review, merge and for > others to rework existing series. So let's say it's cost a person year > of a relatively junior engineer producing the patches and say 100h of > review and application time. The latter is likely the big ticket item > because it's what we have in least supply in the kernel (even though > it's 20x vs the producer time). How are you arriving at such numbers? It is a total of ~200 trivial lines. > It's not about the risk of the changes it's about the cost of > implementing them. Even if you discount the producer time (which > someone gets to pay for, and if I were the engineering manager, I'd be > unhappy about), the review/merge/rework time is pretty significant in > exchange for six minor bug fixes. Fine, when a new compiler warning > comes along it's certainly reasonable to see if we can benefit from it > and the fact that the compiler people think it's worthwhile is enough > evidence to assume this initially. But at some point you have to ask > whether that assumption is supported by the evidence we've accumulated > over the time we've been using it. And if the evidence doesn't support > it perhaps it is time to stop the experiment. Maintainers routinely review 1-line trivial patches, not to mention internal API changes, etc. If some company does not want to pay for that, that's fine, but they don't get to be maintainers and claim `Supported`. Cheers, Miguel -- linux-i3c mailing list linux-i3c@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-i3c From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miguel Ojeda Date: Mon, 23 Nov 2020 15:19:55 +0100 Subject: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang In-Reply-To: <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On Sun, Nov 22, 2020 at 11:36 PM James Bottomley wrote: > > Well, it seems to be three years of someone's time plus the maintainer > review time and series disruption of nearly a thousand patches. Let's > be conservative and assume the producer worked about 30% on the series > and it takes about 5-10 minutes per patch to review, merge and for > others to rework existing series. So let's say it's cost a person year > of a relatively junior engineer producing the patches and say 100h of > review and application time. The latter is likely the big ticket item > because it's what we have in least supply in the kernel (even though > it's 20x vs the producer time). How are you arriving at such numbers? It is a total of ~200 trivial lines. > It's not about the risk of the changes it's about the cost of > implementing them. Even if you discount the producer time (which > someone gets to pay for, and if I were the engineering manager, I'd be > unhappy about), the review/merge/rework time is pretty significant in > exchange for six minor bug fixes. Fine, when a new compiler warning > comes along it's certainly reasonable to see if we can benefit from it > and the fact that the compiler people think it's worthwhile is enough > evidence to assume this initially. But at some point you have to ask > whether that assumption is supported by the evidence we've accumulated > over the time we've been using it. And if the evidence doesn't support > it perhaps it is time to stop the experiment. Maintainers routinely review 1-line trivial patches, not to mention internal API changes, etc. If some company does not want to pay for that, that's fine, but they don't get to be maintainers and claim `Supported`. Cheers, Miguel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miguel Ojeda Date: Mon, 23 Nov 2020 15:19:55 +0100 Subject: [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang In-Reply-To: <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sun, Nov 22, 2020 at 11:36 PM James Bottomley wrote: > > Well, it seems to be three years of someone's time plus the maintainer > review time and series disruption of nearly a thousand patches. Let's > be conservative and assume the producer worked about 30% on the series > and it takes about 5-10 minutes per patch to review, merge and for > others to rework existing series. So let's say it's cost a person year > of a relatively junior engineer producing the patches and say 100h of > review and application time. The latter is likely the big ticket item > because it's what we have in least supply in the kernel (even though > it's 20x vs the producer time). How are you arriving at such numbers? It is a total of ~200 trivial lines. > It's not about the risk of the changes it's about the cost of > implementing them. Even if you discount the producer time (which > someone gets to pay for, and if I were the engineering manager, I'd be > unhappy about), the review/merge/rework time is pretty significant in > exchange for six minor bug fixes. Fine, when a new compiler warning > comes along it's certainly reasonable to see if we can benefit from it > and the fact that the compiler people think it's worthwhile is enough > evidence to assume this initially. But at some point you have to ask > whether that assumption is supported by the evidence we've accumulated > over the time we've been using it. And if the evidence doesn't support > it perhaps it is time to stop the experiment. Maintainers routinely review 1-line trivial patches, not to mention internal API changes, etc. If some company does not want to pay for that, that's fine, but they don't get to be maintainers and claim `Supported`. Cheers, Miguel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WUYMqcUnfpAQa1YuH9tQ3ze5bp2bxaoGLXc9Sg/470Y=; b=b0LkeT2q71Z3peIccxL7MkU5QadaCN3igdEC89IE4ykmdOxIlhuoo/0+H7pQCoNmlh 0UX19Z7soasUpz2fDZHX56luUWrH4GLKAJ9K28HwPu9km7qlcvasqfBffaQW+LtXvh6a fVP4J8wQFxbi1QWFB10Wsq9dLONxRShLcqQtcaktrZCy3tSRV5R4FOw2MSdgwNuCxNwd cKQMyE/jYgmlc9Qm972BZKz9xJaasT5iW6gpZgai8YpCh1sxJNgZFzlfCpv21Fvd7rwb akOsznbnFT4mJT95mXFDUPnplTdAJirWAcm8YfzHFRAfOGn9Vk91PuRcq7JipLelDPMB VWgQ== MIME-Version: 1.0 References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> In-Reply-To: <1c7d7fde126bc0acf825766de64bf2f9b888f216.camel@HansenPartnership.com> From: Miguel Ojeda Date: Mon, 23 Nov 2020 15:19:55 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: James Bottomley Cc: alsa-devel@alsa-project.org, linux-atm-general@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, linux-iio@vger.kernel.org, linux-wireless , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "Gustavo A. R. Silva" , Nathan Chancellor , linux-ide@vger.kernel.org, dm-devel@redhat.com, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, GR-everest-linux-l2@marvell.com, wcn36xx@lists.infradead.org, samba-technical@lists.samba.org, linux-i3c@lists.infradead.org, linux1394-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, usb-storage@lists.one-eyed-alien.net, drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, Nick Desaulniers , linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, oss-drivers@netronome.com, bridge@lists.linux-foundation.org, linux-security-module@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, coreteam@netfilter.org, intel-wired-lan@lists.osuosl.org, linux-input , Miguel Ojeda , Jakub Kicinski , Ext4 Developers List , Linux Media Mailing List , Kees Cook , selinux@vger.kernel.org, linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-geode@lists.infradead.org, linux-can@vger.kernel.org, linux-block@vger.kernel.org, linux-gpio@vger.kernel.org, op-tee@lists.trustedfirmware.org, linux-mediatek@lists.infradead.org, xen-devel@lists.xenproject.org, nouveau@lists.freedesktop.org, linux-hams@vger.kernel.org, ceph-devel@vger.kernel.org, virtualization@lists.linux-foundation.org, Linux ARM , linux-hwmon@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-nfs@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com, tipc-discussion@lists.sourceforge.net, Linux-MM , Network Development , linux-decnet-user@lists.sourceforge.net, linux-mmc@vger.kernel.org, linux-kernel , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , linux-renesas-soc@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, netfilter-devel@vger.kernel.org, Linux Crypto Mailing List , patches@opensource.cirrus.com, Joe Perches , linux-integrity@vger.kernel.org, target-devel@vger.kernel.org, linux-hardening@vger.kernel.org On Sun, Nov 22, 2020 at 11:36 PM James Bottomley wrote: > > Well, it seems to be three years of someone's time plus the maintainer > review time and series disruption of nearly a thousand patches. Let's > be conservative and assume the producer worked about 30% on the series > and it takes about 5-10 minutes per patch to review, merge and for > others to rework existing series. So let's say it's cost a person year > of a relatively junior engineer producing the patches and say 100h of > review and application time. The latter is likely the big ticket item > because it's what we have in least supply in the kernel (even though > it's 20x vs the producer time). How are you arriving at such numbers? It is a total of ~200 trivial lines. > It's not about the risk of the changes it's about the cost of > implementing them. Even if you discount the producer time (which > someone gets to pay for, and if I were the engineering manager, I'd be > unhappy about), the review/merge/rework time is pretty significant in > exchange for six minor bug fixes. Fine, when a new compiler warning > comes along it's certainly reasonable to see if we can benefit from it > and the fact that the compiler people think it's worthwhile is enough > evidence to assume this initially. But at some point you have to ask > whether that assumption is supported by the evidence we've accumulated > over the time we've been using it. And if the evidence doesn't support > it perhaps it is time to stop the experiment. Maintainers routinely review 1-line trivial patches, not to mention internal API changes, etc. If some company does not want to pay for that, that's fine, but they don't get to be maintainers and claim `Supported`. Cheers, Miguel