From: SF Markus Elfring <elfring@users.sourceforge.net>
To: Joe Perches <joe@perches.com>,
Jonathan Cameron <jic23@jic23.retrosnub.co.uk>,
linux-iio@vger.kernel.org, linux-input@vger.kernel.org
Cc: Jonathan Cameron <jic23@kernel.org>,
Hartmut Knaack <knaack.h@gmx.de>, Jiri Kosina <jikos@kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
LKML <linux-kernel@vger.kernel.org>,
kernel-janitors@vger.kernel.org
Subject: Re: Software evolution around “checkpatch.pl”?
Date: Sat, 10 Feb 2018 18:30:15 +0000 [thread overview]
Message-ID: <a988eca2-36d4-19bd-e92c-1a92e497e0da@users.sourceforge.net> (raw)
In-Reply-To: <1518284577.16865.8.camel@perches.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1444 bytes --]
>> So I think checkpatch is striking the right balance here in
>> how it warns. Obviously if it could assess the text
>> and come to an informed decision that would be great but
>> we are some way from that ;)
>
> The 'informed' bit is difficult as it is mostly a political problem.
I find such a view very interesting.
> I just wish Markus would improve his consistently terrible commit messages
I tried to achieve another clarification a few times.
> that just restate the action being done and detail
> _why_ a particular thing _should_ be done.
Unfortunately, it seems that no other contributors picked
corresponding opportunities up so far.
You indicated also special software development challenges in your commit
âcheckpatch: attempt to find unnecessary 'out of memory' messagesâ.
https://lkml.org/lkml/2014/6/10/382
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?idëfdc40969f24fc0cdd1349835d36e8ebae05374
> His acceptance rate would improve as many of these back and forth
> replies for what trivialities he posts as patches would be minimized.
My selection of change possibilities leads to mixed integration results.
I stumbled on variations for general change resistance.
Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: SF Markus Elfring <elfring@users.sourceforge.net>
To: Joe Perches <joe@perches.com>,
Jonathan Cameron <jic23@jic23.retrosnub.co.uk>,
linux-iio@vger.kernel.org, linux-input@vger.kernel.org
Cc: Jonathan Cameron <jic23@kernel.org>,
Hartmut Knaack <knaack.h@gmx.de>, Jiri Kosina <jikos@kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
LKML <linux-kernel@vger.kernel.org>,
kernel-janitors@vger.kernel.org
Subject: Re: Software evolution around “checkpatch.pl”?
Date: Sat, 10 Feb 2018 19:30:15 +0100 [thread overview]
Message-ID: <a988eca2-36d4-19bd-e92c-1a92e497e0da@users.sourceforge.net> (raw)
In-Reply-To: <1518284577.16865.8.camel@perches.com>
>> So I think checkpatch is striking the right balance here in
>> how it warns. Obviously if it could assess the text
>> and come to an informed decision that would be great but
>> we are some way from that ;)
>
> The 'informed' bit is difficult as it is mostly a political problem.
I find such a view very interesting.
> I just wish Markus would improve his consistently terrible commit messages
I tried to achieve another clarification a few times.
> that just restate the action being done and detail
> _why_ a particular thing _should_ be done.
Unfortunately, it seems that no other contributors picked
corresponding opportunities up so far.
You indicated also special software development challenges in your commit
“checkpatch: attempt to find unnecessary 'out of memory' messages”.
https://lkml.org/lkml/2014/6/10/382
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebfdc40969f24fc0cdd1349835d36e8ebae05374
> His acceptance rate would improve as many of these back and forth
> replies for what trivialities he posts as patches would be minimized.
My selection of change possibilities leads to mixed integration results.
I stumbled on variations for general change resistance.
Regards,
Markus
next prev parent reply other threads:[~2018-02-10 18:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-31 21:26 [PATCH] hid-sensor-accel-3d: Delete an error message for a failed memory allocation in hid_accel_3d_ SF Markus Elfring
2018-01-31 21:26 ` [PATCH] hid-sensor-accel-3d: Delete an error message for a failed memory allocation in hid_accel_3d_probe() SF Markus Elfring
2018-02-04 11:23 ` [PATCH] hid-sensor-accel-3d: Delete an error message for a failed memory allocation in hid_accel Jonathan Cameron
2018-02-04 11:23 ` [PATCH] hid-sensor-accel-3d: Delete an error message for a failed memory allocation in hid_accel_3d_probe() Jonathan Cameron
2018-02-05 18:26 ` hid-sensor-accel-3d: Delete an error message for a failed memory allocation in hid_accel_3d_prob SF Markus Elfring
2018-02-05 18:26 ` hid-sensor-accel-3d: Delete an error message for a failed memory allocation in hid_accel_3d_probe() SF Markus Elfring
2018-02-05 21:51 ` hid-sensor-accel-3d: Delete an error message for a failed memory allocation in hid_accel_3d_prob Jonathan Cameron
2018-02-05 21:51 ` hid-sensor-accel-3d: Delete an error message for a failed memory allocation in hid_accel_3d_probe() Jonathan Cameron
2018-02-05 21:51 ` Jonathan Cameron
2018-02-06 8:45 ` Software evolution around “checkpatch.pl”? SF Markus Elfring
2018-02-06 8:45 ` SF Markus Elfring
2018-02-10 14:53 ` Jonathan Cameron
2018-02-10 14:59 ` Joe Perches
2018-02-10 14:59 ` Joe Perches
2018-02-10 14:59 ` Joe Perches
2018-02-10 15:57 ` Jonathan Cameron
2018-02-10 15:57 ` Jonathan Cameron
2018-02-10 15:57 ` Jonathan Cameron
2018-02-10 17:42 ` Joe Perches
2018-02-10 17:42 ` Joe Perches
2018-02-10 17:42 ` Joe Perches
2018-02-10 18:30 ` SF Markus Elfring [this message]
2018-02-10 18:30 ` SF Markus Elfring
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=a988eca2-36d4-19bd-e92c-1a92e497e0da@users.sourceforge.net \
--to=elfring@users.sourceforge.net \
--cc=jic23@jic23.retrosnub.co.uk \
--cc=jic23@kernel.org \
--cc=jikos@kernel.org \
--cc=joe@perches.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
--cc=srinivas.pandruvada@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.