From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, 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 553A4C64E8A for ; Sat, 21 Nov 2020 18:02:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 297BB2224E for ; Sat, 21 Nov 2020 18:02:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727426AbgKUSC1 (ORCPT ); Sat, 21 Nov 2020 13:02:27 -0500 Received: from smtprelay0210.hostedemail.com ([216.40.44.210]:53086 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726556AbgKUSC0 (ORCPT ); Sat, 21 Nov 2020 13:02:26 -0500 Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id AF7D7181D3025; Sat, 21 Nov 2020 18:02:23 +0000 (UTC) X-Session-Marker: 6A6F6540706572636865732E636F6D X-HE-Tag: uncle36_3402e8c27356 X-Filterd-Recvd-Size: 3937 Received: from XPS-9350.home (unknown [47.151.128.180]) (Authenticated sender: joe@perches.com) by omf04.hostedemail.com (Postfix) with ESMTPA; Sat, 21 Nov 2020 18:02:18 +0000 (UTC) Message-ID: Subject: Re: [RFC] MAINTAINERS tag for cleanup robot From: Joe Perches To: James Bottomley , trix@redhat.com, clang-built-linux@googlegroups.com Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, tboot-devel@lists.sourceforge.net, kvm@vger.kernel.org, linux-crypto@vger.kernel.org, linux-acpi@vger.kernel.org, devel@acpica.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, netdev@vger.kernel.org, linux-media@vger.kernel.org, MPT-FusionLinux.pdl@broadcom.com, linux-scsi@vger.kernel.org, linux-wireless@vger.kernel.org, ibm-acpi-devel@lists.sourceforge.net, platform-driver-x86@vger.kernel.org, linux-usb@vger.kernel.org, linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, ecryptfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, cluster-devel@redhat.com, linux-mtd@lists.infradead.org, keyrings@vger.kernel.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, alsa-devel@alsa-project.org, bpf@vger.kernel.org, linux-bluetooth@vger.kernel.org, linux-nfs@vger.kernel.org, patches@opensource.cirrus.com Date: Sat, 21 Nov 2020 10:02:17 -0800 In-Reply-To: <5843ef910b0e86c00d9c0143dec20f93823b016b.camel@HansenPartnership.com> References: <20201121165058.1644182-1-trix@redhat.com> <5843ef910b0e86c00d9c0143dec20f93823b016b.camel@HansenPartnership.com> Content-Type: text/plain; charset="ISO-8859-1" User-Agent: Evolution 3.38.1-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-fbdev@vger.kernel.org On Sat, 2020-11-21 at 09:18 -0800, James Bottomley wrote: > On Sat, 2020-11-21 at 08:50 -0800, trix@redhat.com wrote: > > A difficult part of automating commits is composing the subsystem > > preamble in the commit log. For the ongoing effort of a fixer > > producing one or two fixes a release the use of 'treewide:' does > > not seem appropriate. > > > > It would be better if the normal prefix was used. Unfortunately > > normal is not consistent across the tree. > > > > D: Commit subsystem prefix > > > > ex/ for FPGA DFL DRIVERS > > > > D: fpga: dfl: > > I've got to bet this is going to cause more issues than it solves. > SCSI uses scsi: : for drivers but not every driver has a > MAINTAINERS entry. We use either scsi: or scsi: core: for mid layer > things, but we're not consistent. Block uses blk-: for all > of it's stuff but almost no s have a MAINTAINERS entry. So > the next thing you're going to cause is an explosion of suggested > MAINTAINERs entries. As well as some changes require simultaneous changes across multiple subsystems. > Has anyone actually complained about treewide:? It depends on what you mean by treewide: If a treewide: patch is applied by some "higher level" maintainer, then generally, no. If the treewide patch is also cc'd to many individual maintainers, then yes, many many times. Mostly because patches cause what is in their view churn or that changes are not specific to their subsystem grounds. The treewide patch is sometimes dropped, sometimes broken up and generally not completely applied. What would be useful in many cases like this is for a pre and post application of the treewide patch to be compiled and the object code verified for lack of any logic change. Unfortunately, gcc does not guarantee deterministic compilation so this isn't feasible with at least gcc. Does clang guarantee this? I'm not sure it's possible: https://blog.llvm.org/2019/11/deterministic-builds-with-clang-and-lld.html