From: Leon Romanovsky <leon@kernel.org>
To: Knut Omang <knut.omang@oracle.com>
Cc: Bart Van Assche <Bart.VanAssche@wdc.com>,
"joe@perches.com" <joe@perches.com>,
"jgg@ziepe.ca" <jgg@ziepe.ca>, "corbet@lwn.net" <corbet@lwn.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"keescook@chromium.org" <keescook@chromium.org>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"willy@infradead.org" <willy@infradead.org>,
"nicolas.palix@imag.fr" <nicolas.palix@imag.fr>,
"asmund.ostvold@oracle.com" <asmund.ostvold@oracle.com>,
"john.haxby@oracle.com" <john.haxby@oracle.com>,
"alexander.levin@verizon.com" <alexander.levin@verizon.com>,
"mchehab@kernel.org" <mchehab@kernel.org>,
"haakon.bugge@oracle.com" <haakon.bugge@oracle.com>,
"michal.lkml@markovi.net" <michal.lkml@markovi.net>,
Subject: Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program
Date: Mon, 18 Dec 2017 21:24:36 +0200 [thread overview]
Message-ID: <20171218192436.GF18894@mtr-leonro.local> (raw)
In-Reply-To: <1513622390.31439.239.camel@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]
On Mon, Dec 18, 2017 at 07:39:50PM +0100, Knut Omang wrote:
> On Mon, 2017-12-18 at 17:56 +0000, Bart Van Assche wrote:
> > On Mon, 2017-12-18 at 10:46 -0700, Jason Gunthorpe wrote:
> > > On Sun, Dec 17, 2017 at 10:00:17PM -0800, Joe Perches wrote:
> > >
> > > > > Today when we run checkers we get so many warnings it is too hard to
> > > > > make any sense of it.
> > > >
> > > > Here is a list of the checkpatch messages for drivers/infiniband
> > > > sorted by type.
> > > >
> > > > Many of these might be corrected by using
> > > >
> > > > $ ./scripts/checkpatch.pl -f --fix-inplace --types=<TYPE> \
> > > > $(git ls-files drivers/infiniband/)
> > >
> > > How many of these do you think it is worth to fix?
> > >
> > > We do get a steady trickle of changes in this topic every cycle.
> > >
> > > Is it better to just do a big number of them all at once? Do you have
> > > an idea how disruptive this kind of work is to the whole patch flow
> > > eg new patches no longer applying to for-next, backports no longer
> > > applying, merge conflicts?
> >
> > In my opinion patches that only change the coding style and do not change any
> > functionality are annoying. Before posting a patch that fixes a bug the change
> > history (git log -p) has to be cheched to figure out which patch introduced
> > the bug. Patches that only change coding style pollute the change history.
>
> I agree with you - the problem is that style issues should not have existed.
> But when they do it becomes a problem to remove them and a problem to
> keep them - for instance us who try to be compliant by having style helpers
> in our editor, we end up having to manually revert old style mistakes back in
> to avoid making unrelated whitespace changes or similar.
If the checkpatch.pl complains about coding style for the new patch in
newly added code, I'm asking from the author to prepare cleanup patch so
it will be applied before actual patch.
In case, complains are for code which patch are not touching, I'm
submitting it as is.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-12-18 19:24 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-16 14:42 [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program Knut Omang
2017-12-16 14:42 ` [PATCH v2 4/5] rds: Add runchecks.cfg for net/rds Knut Omang
2017-12-16 17:45 ` Stephen Hemminger
2017-12-16 18:24 ` Joe Perches
2017-12-16 20:00 ` santosh.shilimkar
[not found] ` <499ec5ae-d1d5-3bb2-8e10-de48283a1c2e-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2017-12-17 2:02 ` Knut Omang
[not found] ` <1513476136.31439.96.camel-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2017-12-18 19:28 ` Santosh Shilimkar
2017-12-17 1:57 ` Knut Omang
2017-12-17 1:46 ` Knut Omang
[not found] ` <cover.630ac8faeeda67bf7a778c158174422042942d08.1513430008.git-series.knut.omang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2017-12-16 17:47 ` [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program Stephen Hemminger
2017-12-16 18:02 ` Joe Perches
2017-12-17 2:14 ` Knut Omang
2017-12-18 5:00 ` Jason Gunthorpe
2017-12-18 6:00 ` Joe Perches
2017-12-18 13:05 ` Knut Omang
[not found] ` <1513602315.22938.49.camel-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2017-12-18 15:30 ` Joe Perches
2017-12-18 16:41 ` Knut Omang
2017-12-18 17:49 ` Jason Gunthorpe
[not found] ` <1513576817.31581.58.camel-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
2017-12-18 17:46 ` Jason Gunthorpe
2017-12-18 17:53 ` Joe Perches
2017-12-18 17:56 ` Bart Van Assche
2017-12-18 18:39 ` Knut Omang
2017-12-18 19:24 ` Leon Romanovsky [this message]
[not found] ` <20171218050043.GA1307-uk2M96/98Pc@public.gmane.org>
2017-12-18 13:41 ` Knut Omang
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=20171218192436.GF18894@mtr-leonro.local \
--to=leon@kernel.org \
--cc=Bart.VanAssche@wdc.com \
--cc=alexander.levin@verizon.com \
--cc=asmund.ostvold@oracle.com \
--cc=corbet@lwn.net \
--cc=haakon.bugge@oracle.com \
--cc=jgg@ziepe.ca \
--cc=joe@perches.com \
--cc=john.haxby@oracle.com \
--cc=keescook@chromium.org \
--cc=knut.omang@oracle.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=nicolas.palix@imag.fr \
--cc=willy@infradead.org \
/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).