From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: Joe Perches <joe@perches.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
Jens Axboe <axboe@kernel.dk>,
Dan Carpenter <dan.carpenter@oracle.com>,
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: Thu, 12 Sep 2019 16:42:03 +0200 [thread overview]
Message-ID: <CANiq72ntjDRyMBdVXLMV9h=3_jU47UA06LaGvR2Jw9aMZM3V3w@mail.gmail.com> (raw)
In-Reply-To: <e9cb9bc8bd7fe38a5bb6ff7b7222b512acc7b018.camel@perches.com>
On Thu, Sep 12, 2019 at 12:18 PM Joe Perches <joe@perches.com> wrote:
>
> I don't think that's close to true yet for clang-format.
I don't expect clang-format to match perfectly our current code style.
However, if core maintainers agree that it is "close enough now"
(specially with newer LLVMs, like 9), then there is a great benefit on
moving to automatically-styled code. The "con" is having to change a
bit our style wherever clang-format does not support exactly our
current style.
> For instance: clang-format does not do anything with
> missing braces, or coalescing multi-part strings,
> or any number of other nominal coding style defects
> like all the for_each macros, aligning or not aligning
> columnar contents appropriately, etc...
Some of these may or may not be fixable tweaking the options. Note
that there are conflicting styles within the kernel at the moment,
e.g. how to indent arguments to function calls. Therefore, some of the
differences do not apply as soon as we decide on a given style.
Furthermore, with automatic formatting we have also the chance to
review some options that we couldn't easily change before.
> clang-format as yet has no taste.
>
> I believe it'll take a lot of work to improve it to a point
> where its formatting is acceptable and appropriate.
>
> An AI rather than a table based system like clang-format is
> more likely to be a real solution, but training that AI
> isn't a thing that I want to do.
I don't think we need taste (or AI-like solutions), because
consistency has a lot of value too. Not just for our brains, but for
patches as well.
Note that clang-format is a tool used by major projects successfully,
it is not like we are experimenting too much here :-)
Cheers,
Miguel
next prev parent reply other threads:[~2019-09-12 14:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <156821692280.2951081.18036584954940423225.stgit@dwillia2-desk3.amr.corp.intel.com>
[not found] ` <156821693963.2951081.11214256396118531359.stgit@dwillia2-desk3.amr.corp.intel.com>
2019-09-11 18:43 ` [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile 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 14:42 ` Miguel Ojeda [this message]
2019-09-13 7:09 ` Jonathan Corbet
2019-09-13 11:48 ` Dan Carpenter
2019-09-13 12:18 ` Dan Williams
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
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='CANiq72ntjDRyMBdVXLMV9h=3_jU47UA06LaGvR2Jw9aMZM3V3w@mail.gmail.com' \
--to=miguel.ojeda.sandonis@gmail.com \
--cc=axboe@kernel.dk \
--cc=bpf@vger.kernel.org \
--cc=dan.carpenter@oracle.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=joe@perches.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).