BPF Archive on lore.kernel.org
 help / color / Atom feed
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>,
Subject: Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
Date: Thu, 12 Sep 2019 16:42:03 +0200
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 :-)


  reply index

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   ` 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:

* 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 \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

BPF Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/bpf/0 bpf/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 bpf bpf/ https://lore.kernel.org/bpf \
	public-inbox-index bpf

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git