[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190913010937.7fc20d93@lwn.net>
Date: Fri, 13 Sep 2019 01:09:37 -0600
From: Jonathan Corbet <corbet@....net>
To: Jens Axboe <axboe@...nel.dk>
Cc: Dan Carpenter <dan.carpenter@...cle.com>,
Dan Williams <dan.j.williams@...el.com>,
Dave Jiang <dave.jiang@...el.com>,
ksummit-discuss@...ts.linuxfoundation.org,
linux-nvdimm@...ts.01.org, Vishal Verma <vishal.l.verma@...el.com>,
linux-kernel@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS:
Maintainer Entry Profile
On Wed, 11 Sep 2019 16:11:29 -0600
Jens Axboe <axboe@...nel.dk> 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
Powered by blists - more mailing lists