From: Dan Carpenter <dan.carpenter@linaro.org>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: Prithvi <activprithvi@gmail.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
gregkh@linuxfoundation.org, abrahamadekunle50@gmail.com,
straube.linux@gmail.com, b9788213@gmail.com,
ethantidmore06@gmail.com, weibu@redadmin.org,
knavaneeth786@gmail.com, ignacio.pena87@gmail.com,
dharanitharan725@gmail.com, lukagejak5@gmail.com,
samasth.norway.ananda@oracle.com, karanja99erick@gmail.com,
s9430939@naver.com, suunj1331@gmail.com, ysinghcin@gmail.com,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-kernel-mentees@lists.linux.dev,
david.hunter.linux@gmail.com, khalid@kernel.org
Subject: Re: [PATCH v2] staging: rtl8723bs: fix constant on left side of test checkpatch warnings
Date: Thu, 26 Mar 2026 00:34:48 +0300 [thread overview]
Message-ID: <acRU-NKBqLe4-e3E@stanley.mountain> (raw)
In-Reply-To: <ea43143b-a880-4d15-9fd6-1a4a25abf187@linuxfoundation.org>
[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]
On Wed, Mar 25, 2026 at 11:57:38AM -0600, Shuah Khan wrote:
> My primary concern with this change is that it 10 files changed, with
> 26 insertions(+), 32 deletions(-)
>
> It can be difficult to find any regressions unless the changes are
> tested. I understand it is staging repo, but if we relax the rules
> for staging irrespective of the scope of change, it becomes lot
> harder to find regressions later. We are essentially leaving the
> job of testing to users. Also if ans when the driver is pulled into
> mainline, it will inherit the regressions that crept in.
>
To me this is a mechanical patch (basically automatic, flip the
if statement) from a newbie. These kinds of patches are seldom a
problem.
I took a sample of the patches for five years from 2021 to the end of
2025. We merged 54406 commits in staging. We had 401 Fixes tags. But
then I decided I don't care about Kconfig problems so I cut it down to
380 bugs. Half of those (189 commits) were from when the driver was
merged. We tend to not review code very much when it is first merged
to staging. The other half (191 commits) were from us missing bugs
during review. 191 bugs over five years is 40 bugs per year.
I hand reviewed a bunch of the 191 commits. It's mostly senior
developers and maintainers who introduce bugs. They are normally doing
complicated things like adding features or re-working core parts of the
driver. Quite a few of these patches were tested.
The fallout from newbie patches is pretty rare and often really
minor. A common thing is "We deleted code but we didn't delete
everything." The number of serious mess ups is probably just a
couple times per year out of the 40 total bugs per year.
I've attached my script so you can check yourself. NEW means the
bug was introduced by a new driver. OLD means, ideally it would
have been caught in review.
regards,
dan carpenter
[-- Attachment #2: old_v_new.sh --]
[-- Type: application/x-sh, Size: 890 bytes --]
next prev parent reply other threads:[~2026-03-25 21:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 16:29 [PATCH v2] staging: rtl8723bs: fix constant on left side of test checkpatch warnings Prithvi Tambewagh
2026-03-23 16:42 ` Andy Shevchenko
2026-03-24 13:02 ` Prithvi
2026-03-24 13:43 ` Andy Shevchenko
2026-03-24 13:55 ` Prithvi
2026-03-24 14:05 ` Andy Shevchenko
2026-03-24 16:02 ` Prithvi
2026-03-24 17:41 ` Shuah Khan
2026-03-25 7:22 ` Dan Carpenter
2026-03-25 17:57 ` Shuah Khan
2026-03-25 21:34 ` Dan Carpenter [this message]
2026-03-25 22:22 ` Shuah Khan
2026-03-28 17:47 ` Prithvi
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=acRU-NKBqLe4-e3E@stanley.mountain \
--to=dan.carpenter@linaro.org \
--cc=abrahamadekunle50@gmail.com \
--cc=activprithvi@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=b9788213@gmail.com \
--cc=david.hunter.linux@gmail.com \
--cc=dharanitharan725@gmail.com \
--cc=ethantidmore06@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=ignacio.pena87@gmail.com \
--cc=karanja99erick@gmail.com \
--cc=khalid@kernel.org \
--cc=knavaneeth786@gmail.com \
--cc=linux-kernel-mentees@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=lukagejak5@gmail.com \
--cc=s9430939@naver.com \
--cc=samasth.norway.ananda@oracle.com \
--cc=skhan@linuxfoundation.org \
--cc=straube.linux@gmail.com \
--cc=suunj1331@gmail.com \
--cc=weibu@redadmin.org \
--cc=ysinghcin@gmail.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