From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
workflows@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH v2] docs: submitting-patches: Clarify half-baked review tags
Date: Thu, 5 Nov 2026 10:50:21 +0200 [thread overview]
Message-ID: <auxDTdfMVS3yazCk@shikoro> (raw)
In-Reply-To: <20261105082729.19622-2-krzysztof.kozlowski@oss.qualcomm.com>
> +If the reviewer checks only a piece of the patch, leaving the rest unreviewed,
> +then more appropriate is Acked-by tag or adding a "# subpart-name" marker
"... is an Acked-by ..."?
> +after the Reviewed-by tag:
> +
> + Reviewed-by: I Did Not Read Everything <foo@example.org> # bar, baz
How about being more specific?
+ Reviewed-by: Driver X author <foo@example.org> # for Driver X
TBH, I think the above is even better than a generic "Acked-by" which is
basically "Yeah, I didn't look in detail but the general approach looks
fine". Which is not what the above says. The above says: "I didn't check
the general approach, but assuming it is okay, the changes to my driver
are correct". If I get a couple of those, then I know which parts have
been reviewed and which have not. A list of generic Acked-bys will not
provide that information. So, actually, I think even the Acked-by should
have the "# subpart name" once only a part of the patch has been looked
at. Ack/Rev is then describing the thoroughness of that look.
Do you get what I mean?
next prev parent reply other threads:[~2026-11-05 8:50 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 8:27 [PATCH v2] docs: submitting-patches: Clarify half-baked review tags Krzysztof Kozlowski
2026-11-05 8:50 ` Wolfram Sang [this message]
2026-11-05 8:57 ` Krzysztof Kozlowski
2026-11-05 9:06 ` Wolfram Sang
2026-11-05 9:12 ` Krzysztof Kozlowski
2026-11-05 9:26 ` Andy Shevchenko
2026-11-05 10:59 ` Krzysztof Kozlowski
2026-11-05 9:28 ` Wolfram Sang
2026-11-05 11:03 ` Krzysztof Kozlowski
2026-11-05 11:19 ` Wolfram Sang
2026-11-05 11:53 ` Andy Shevchenko
2026-11-05 12:56 ` Krzysztof Kozlowski
2026-11-05 14:14 ` Andy Shevchenko
2026-11-05 9:29 ` Geert Uytterhoeven
2026-11-05 9:44 ` Wolfram Sang
2026-11-05 9:47 ` Andy Shevchenko
2026-11-05 9:19 ` Andy Shevchenko
2026-11-05 9:27 ` Krzysztof Kozlowski
2026-11-05 9:48 ` Andy Shevchenko
2026-11-05 10:55 ` Krzysztof Kozlowski
2026-11-05 9:30 ` Jürgen Groß
2026-11-05 15:33 ` Krzysztof Kozlowski
2026-11-05 15:44 ` Juergen Gross
2026-11-05 15:53 ` Krzysztof Kozlowski
2026-11-05 15:59 ` Jürgen Groß
2026-11-05 16:22 ` Krzysztof Kozlowski
2026-11-09 23:42 ` Andy Shevchenko
2026-11-09 23:44 ` Andy Shevchenko
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=auxDTdfMVS3yazCk@shikoro \
--to=wsa+renesas@sang-engineering.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=corbet@lwn.net \
--cc=krzysztof.kozlowski@oss.qualcomm.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=skhan@linuxfoundation.org \
--cc=workflows@vger.kernel.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 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.