lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAJZ5v0jJ6GFm4LFCR2V3qvD9rZrVw=pXyXSjSWPYtQudg-F3xg@mail.gmail.com> Date: Mon, 23 Nov 2020 17:24:51 +0100 From: "Rafael J. Wysocki" <rafael@...nel.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>, "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." <alsa-devel@...a-project.org>, amd-gfx list <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 <dri-devel@...ts.freedesktop.org>, GR-everest-linux-l2@...vell.com, GR-Linux-NIC-Dev@...vell.com, intel-gfx <intel-gfx@...ts.freedesktop.org>, intel-wired-lan@...ts.osuosl.org, keyrings@...r.kernel.org, linux1394-devel@...ts.sourceforge.net, ACPI Devel Maling List <linux-acpi@...r.kernel.org>, linux-afs@...ts.infradead.org, Linux ARM <linux-arm-kernel@...ts.infradead.org>, linux-arm-msm <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>, "open list:FRAMEBUFFER LAYER" <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, "open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)" <linux-ide@...r.kernel.org>, linux-iio@...r.kernel.org, linux-input <linux-input@...r.kernel.org>, linux-integrity@...r.kernel.org, "moderated list:ARM/Mediatek SoC..." <linux-mediatek@...ts.infradead.org>, Linux Media Mailing List <linux-media@...r.kernel.org>, linux-mmc <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 <linux-renesas-soc@...r.kernel.org>, "open list:TARGET SUBSYSTEM" <linux-scsi@...r.kernel.org>, linux-sctp@...r.kernel.org, linux-security-module@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com, "open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:" <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 <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 4:58 PM James Bottomley <James.Bottomley@...senpartnership.com> 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: [cut] > > > > 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 Right. > 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. > > > If some company does not want to pay for that, that's fine, but they > > don't get to be maintainers and claim `Supported`. > > What I'm actually trying to articulate is a way of measuring value of > the patch vs cost ... it has nothing really to do with who foots the > actual bill. > > One thesis I'm actually starting to formulate is that this continual > devaluing of maintainers is why we have so much difficulty keeping and > recruiting them. Absolutely. This is just one of the factors involved, but a significant one IMV.
Powered by blists - more mailing lists