From: Dan Williams <dan.j.williams@intel.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Jonathan Corbet <corbet@lwn.net>, Jens Axboe <axboe@kernel.dk>,
Dave Jiang <dave.jiang@intel.com>,
ksummit <ksummit-discuss@lists.linuxfoundation.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
Vishal Verma <vishal.l.verma@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
bpf@vger.kernel.org
Subject: Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
Date: Fri, 13 Sep 2019 05:18:22 -0700 [thread overview]
Message-ID: <CAPcyv4jPpxS4wxNO-e1pSHdQpKo5=V0YwD1CHqR61g8zmECKfw@mail.gmail.com> (raw)
In-Reply-To: <20190913114849.GP20699@kadam>
On Fri, Sep 13, 2019 at 4:49 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
> On Fri, Sep 13, 2019 at 01:09:37AM -0600, Jonathan Corbet wrote:
> > On Wed, 11 Sep 2019 16:11:29 -0600
> > Jens Axboe <axboe@kernel.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.
>
> There aren't that many subsystem rules. The big exception is
> networking, with the comment style and reverse Chrismas tree
> declarations. Also you have to label which git tree the patch applies
> to like [net] or [net-next].
>
> It used to be that infiniband used "sizeof foo" instead of sizeof(foo)
> but now there is a new maintainer.
>
> There is one subsystem which where the maintainer will capitalize your
> patch prefix and complain. There are others where they will silently
> change it to lower case. (Maybe that has changed in recent years).
>
> There is one subsystem where the maintainer is super strict rules that
> you can't use "I" or "we" in the commit message. So you can't say "I
> noticed a bug while reviewing", you have to say "The code has a bug".
>
> Some maintainers have rules about what you can put in the declaration
> block. No kmalloc() in the declarations is a common rule.
> "struct foo *p = kmalloc();".
>
> Some people (I do) have strict rules for error handling, but most won't
> complain unless the error handling has bugs.
>
> The bpf people want you to put [bpf] or [bpf-next] in the subject.
> Everyone just guesses, and uneducated guesses are worse than leaving it
> blank, but that's just my opinion.
>
> > 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.
>
> I don't think it's shaming, I think it's validating. Everyone just
> insists that since it's written in the Book of Rules then it's our fault
> for not reading it. It's like those EULA things where there is more
> text than anyone can physically read in a life time.
>
> And the documentation doesn't help. For example, I knew people's rules
> about capitalizing the subject but I'd just forget. I say that if you
> can't be bothered to add it to checkpatch then it means you don't really
> care that strongly.
True, can someone with better perl skills than me take a shot at a
rule for checkpatch to catch the capitalization preference based on
the subsystem being touched, or otherwise agree that if a maintainer
has a changelog capitalization preference they just silently fix it up
at application time and not waste time pointing out something so
trivial? For example, I notice Linus likes "-" instead of "*" for
bullet lists in changelogs he just fixes it up silently if I forget.
next prev parent reply other threads:[~2019-09-13 12:18 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-11 15:48 [PATCH v2 0/3] Maintainer Entry Profiles Dan Williams
2019-09-11 15:48 ` [PATCH v2 1/3] MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile Dan Williams
2019-09-13 15:37 ` [Ksummit-discuss] " Mauro Carvalho Chehab
2019-09-11 15:48 ` [PATCH v2 2/3] Maintainer Handbook: " Dan Williams
2019-09-11 17:34 ` [Ksummit-discuss] " Verma, Vishal L
2019-09-16 12:35 ` Jani Nikula
2019-10-01 13:55 ` Jonathan Corbet
2019-10-01 18:17 ` Martin K. Petersen
2019-11-07 20:13 ` Jonathan Corbet
2019-11-08 2:41 ` Dan Williams
2019-09-11 15:48 ` [PATCH v2 3/3] libnvdimm, MAINTAINERS: " Dan Williams
2019-09-11 17:42 ` [Ksummit-discuss] " Vishal Verma
2019-09-11 17:45 ` Dave Jiang
2019-09-11 18:43 ` [Ksummit-discuss] " Dan Carpenter
2019-09-11 22:11 ` Jens Axboe
2019-09-12 7:41 ` Dan Williams
2019-09-12 8:24 ` Miguel Ojeda
2019-09-12 10:18 ` Joe Perches
2019-09-12 11:02 ` Joe Perches
2019-09-12 14:17 ` Dan Williams
2019-09-12 14:51 ` Joe Perches
2019-09-12 14:42 ` Miguel Ojeda
2019-09-13 7:09 ` Jonathan Corbet
2019-09-13 11:48 ` Dan Carpenter
2019-09-13 12:18 ` Dan Williams [this message]
2019-09-13 15:00 ` Randy Dunlap
2019-09-13 15:46 ` Rob Herring
2019-09-13 16:42 ` Joe Perches
2019-09-13 19:32 ` Rob Herring
2019-09-13 17:57 ` Geert Uytterhoeven
2019-09-16 12:42 ` Jani Nikula
2019-09-17 16:16 ` Jason Gunthorpe
2019-09-17 21:59 ` Dan Williams
2019-09-13 21:44 ` Martin K. Petersen
2019-09-16 7:01 ` Dan Carpenter
2019-09-16 17:08 ` Martin K. Petersen
2019-09-16 17:15 ` Mark Brown
2019-09-13 2:11 ` Aneesh Kumar K.V
2019-09-13 5:00 ` Greg KH
2019-09-11 20:30 ` Joe Perches
2019-09-11 16:40 ` [PATCH v2 0/3] Maintainer Entry Profiles Martin K. Petersen
2019-09-12 13:31 ` [Ksummit-discuss] " Bart Van Assche
2019-09-12 15:34 ` Joe Perches
2019-09-12 20:01 ` Bart Van Assche
2019-09-12 20:34 ` Joe Perches
2019-09-13 14:26 ` Rob Herring
2019-09-13 18:42 ` Joe Perches
2019-09-13 19:17 ` Mauro Carvalho Chehab
2019-09-13 20:33 ` Joe Perches
[not found] ` <CAFhKne8Nbk=OnZO_pqPURneVtxcHqbfkH+xJBrAYfCfsntfQ2g@mail.gmail.com>
2019-09-13 13:54 ` Mauro Carvalho Chehab
2019-09-13 14:59 ` Guenter Roeck
2019-09-13 22:03 ` Martin K. Petersen
2020-04-29 13:55 ` Roman Bolshakov
2019-09-12 13:10 ` Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPcyv4jPpxS4wxNO-e1pSHdQpKo5=V0YwD1CHqR61g8zmECKfw@mail.gmail.com' \
--to=dan.j.williams@intel.com \
--cc=axboe@kernel.dk \
--cc=bpf@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=dan.carpenter@oracle.com \
--cc=dave.jiang@intel.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=vishal.l.verma@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).