[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201125090114.GA24274@gofer.mess.org>
Date: Wed, 25 Nov 2020 09:01:14 +0000
From: Sean Young <sean@...s.org>
To: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
Kees Cook <keescook@...omium.org>,
Jakub Kicinski <kuba@...nel.org>,
"Gustavo A. R. Silva" <gustavoars@...nel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
alsa-devel@...a-project.org, amd-gfx@...ts.freedesktop.org,
bridge@...ts.linux-foundation.org, ceph-devel@...r.kernel.org,
cluster-devel@...hat.com, coreteam@...filter.org,
devel@...verdev.osuosl.org, dm-devel@...hat.com,
drbd-dev@...ts.linbit.com, dri-devel@...ts.freedesktop.org,
GR-everest-linux-l2@...vell.com, GR-Linux-NIC-Dev@...vell.com,
intel-gfx@...ts.freedesktop.org, intel-wired-lan@...ts.osuosl.org,
keyrings@...r.kernel.org, linux1394-devel@...ts.sourceforge.net,
linux-acpi@...r.kernel.org, linux-afs@...ts.infradead.org,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
linux-arm-msm@...r.kernel.org,
linux-atm-general@...ts.sourceforge.net,
linux-block@...r.kernel.org, linux-can@...r.kernel.org,
linux-cifs@...r.kernel.org,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
linux-decnet-user@...ts.sourceforge.net,
Ext4 Developers List <linux-ext4@...r.kernel.org>,
linux-fbdev@...r.kernel.org, linux-geode@...ts.infradead.org,
linux-gpio@...r.kernel.org, linux-hams@...r.kernel.org,
linux-hwmon@...r.kernel.org, linux-i3c@...ts.infradead.org,
linux-ide@...r.kernel.org, linux-iio@...r.kernel.org,
linux-input <linux-input@...r.kernel.org>,
linux-integrity@...r.kernel.org,
linux-mediatek@...ts.infradead.org,
Linux Media Mailing List <linux-media@...r.kernel.org>,
linux-mmc@...r.kernel.org, Linux-MM <linux-mm@...ck.org>,
linux-mtd@...ts.infradead.org, linux-nfs@...r.kernel.org,
linux-rdma@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
linux-scsi@...r.kernel.org, linux-sctp@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com,
linux-usb@...r.kernel.org, linux-watchdog@...r.kernel.org,
linux-wireless <linux-wireless@...r.kernel.org>,
Network Development <netdev@...r.kernel.org>,
netfilter-devel@...r.kernel.org, nouveau@...ts.freedesktop.org,
op-tee@...ts.trustedfirmware.org, oss-drivers@...ronome.com,
patches@...nsource.cirrus.com, rds-devel@....oracle.com,
reiserfs-devel@...r.kernel.org, samba-technical@...ts.samba.org,
selinux@...r.kernel.org, target-devel@...r.kernel.org,
tipc-discussion@...ts.sourceforge.net,
usb-storage@...ts.one-eyed-alien.net,
virtualization@...ts.linux-foundation.org,
wcn36xx@...ts.infradead.org,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
xen-devel@...ts.xenproject.org, linux-hardening@...r.kernel.org,
Nick Desaulniers <ndesaulniers@...gle.com>,
Nathan Chancellor <natechancellor@...il.com>,
Miguel Ojeda <ojeda@...nel.org>, Joe Perches <joe@...ches.com>
Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, Nov 23, 2020 at 07:58:06AM -0800, James Bottomley wrote:
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@...senpartnership.com> wrote:
> > > 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.
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
>
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.
You're assuming burn out or recruitment problems is due to patch workload
or too many "trivial" patches.
In my experience, "other maintainers" is by far the biggest cause of
burn out for my kernel maintenance work.
Certainly arguing with a maintainer about some obviously-correct patch
series must be a good example of this.
Sean
Powered by blists - more mailing lists