Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp472149ybe; Fri, 13 Sep 2019 00:32:24 -0700 (PDT) X-Google-Smtp-Source: APXvYqxcvuTJXU01wwNsdD6KXyoX9amHo31Rj5hGzc5NMPUB43MsxVdCKzrOX3gKKyuH1GS22uB5 X-Received: by 2002:a50:ec84:: with SMTP id e4mr47364935edr.193.1568359944060; Fri, 13 Sep 2019 00:32:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568359944; cv=none; d=google.com; s=arc-20160816; b=kWinv1e9t/4/Yts0Yf1HqO28PiL6abYZlhxU2r4VXSI2wMyBm344dP2jBAIICX30nz qSi4zdGoFvXqr0glkmlHLgyxMNMwYkEKQv6O0YAlFKjOor7yDBbEcpijqRlep4iMm4dM w3qJW7u9NAivsleSuppD5BfgYQ3yLCKqh8efUvCJ5mDx7rw/h1xNS2/m5/EsdPdXI9ml 4DlxSvhbODMNXsmGt8T6Lm9wldlzdSff/LPkhNK8W4I/AIsLawk9aNVirOecPpb4su96 GNyktZZgtweqCiI6WUve0akuaOR0vtBLaJ708D3SpKCOExZbmC2yDLyIpzLrcfz7+YK7 8q7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=0P3KtbP5waLPaYjliosQWYBXM8Y0S1igHTP94EXSJHM=; b=b8iXY8eWbhuNMG6n/xMjX+JjOcwu8Ltb0PWOaoRkFBq/BxFZ7wAuMIegiLcVCTcqe4 2bsL82DymHmtsuGqxCpDHEjB0CzngioopgZ/IaceLyH9hA5J4XUxaimHb9labMczscCJ cU7hT+VXyMzJCJs0VVVeXxaJb2Hgys5T3NScQ+ebWRLcTtsoKq0BprrOKFbrfYLiyxm4 8oiD9AAgECW59tFLdbDC/y/cQ/oXo5iktrGkNvQQLO6eFegbkrlcE2N9Z6DLOA4mEWuY Gd0hSQVlBoGvbFqIA4jBryS9FwMVJ+CEb2U91WuxX2AEDiawZxQuDZJe0arXqvgWRVKP eYTQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y22si14021834ejr.99.2019.09.13.00.31.46; Fri, 13 Sep 2019 00:32:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728416AbfIMHJn (ORCPT + 99 others); Fri, 13 Sep 2019 03:09:43 -0400 Received: from ms.lwn.net ([45.79.88.28]:57676 "EHLO ms.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727661AbfIMHJn (ORCPT ); Fri, 13 Sep 2019 03:09:43 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id D794177D; Fri, 13 Sep 2019 07:09:40 +0000 (UTC) Date: Fri, 13 Sep 2019 01:09:37 -0600 From: Jonathan Corbet To: Jens Axboe Cc: Dan Carpenter , Dan Williams , Dave Jiang , ksummit-discuss@lists.linuxfoundation.org, linux-nvdimm@lists.01.org, Vishal Verma , linux-kernel@vger.kernel.org, bpf@vger.kernel.org Subject: Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile Message-ID: <20190913010937.7fc20d93@lwn.net> In-Reply-To: <9132e214-9b57-07dc-7ee2-f6bc52e960c5@kernel.dk> References: <156821692280.2951081.18036584954940423225.stgit@dwillia2-desk3.amr.corp.intel.com> <156821693963.2951081.11214256396118531359.stgit@dwillia2-desk3.amr.corp.intel.com> <20190911184332.GL20699@kadam> <9132e214-9b57-07dc-7ee2-f6bc52e960c5@kernel.dk> Organization: LWN.net X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 11 Sep 2019 16:11:29 -0600 Jens Axboe wrote: > On 9/11/19 12:43 PM, Dan Carpenter wrote: > > > > I kind of hate all this extra documentation because now everyone thinks > > they can invent new hoops to jump through. > > FWIW, I completely agree with Dan (Carpenter) here. I absolutely > dislike having these kinds of files, and with subsystems imposing weird > restrictions on style (like the quoted example, yuck). > > Additionally, it would seem saner to standardize rules around when > code is expected to hit the maintainers hands for kernel releases. Both > yours and Martins deals with that, there really shouldn't be the need > to have this specified in detail per sub-system. This sort of objection came up at the maintainers summit yesterday; the consensus was that, while we might not like subsystem-specific rules, they do currently exist and we're just documenting reality. To paraphrase Phillip K. Dick, reality is that which, when you refuse to document it, doesn't go away. So I'm expecting to take this kind of stuff into Documentation/. My own personal hope is that it can maybe serve to shame some of these "local quirks" out of existence. The evidence from this brief discussion suggests that this might indeed happen. Thanks, jon