From: Krzysztof Kozlowski <krzk@kernel.org>
To: Juergen Gross <jgross@suse.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.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,
Wolfram Sang <wsa+renesas@sang-engineering.com>
Subject: Re: [PATCH v2] docs: submitting-patches: Clarify half-baked review tags
Date: Thu, 5 Nov 2026 16:53:55 +0100 [thread overview]
Message-ID: <76b98471-ae9b-4ff3-8337-b50d75c4b7de@kernel.org> (raw)
In-Reply-To: <f5ac5472-da79-4ac5-82de-36b2f5978f45@suse.com>
On 05/11/2026 16:44, Juergen Gross wrote:
> On 05.11.26 16:33, Krzysztof Kozlowski wrote:
>> On 05/11/2026 10:30, Jürgen Groß wrote:
>>> On 05.11.26 10:19, Andy Shevchenko wrote:
>>>> On Thu, Nov 05, 2026 at 09:27:30AM +0100, Krzysztof Kozlowski wrote:
>>>>> Refactoring of driver subsystems or some core driver parts often come
>>>>> with change of the actual drivers. If that happens within one patch,
>>>>> people giving "Reviewed-by" tag only to piece of the patch, like one
>>>>> driver, and ignoring the rest including the main concept of the patch,
>>>>> are not really reviewing "the patch".
>>>>>
>>>>> As explained in the Submitting Patches document, the "Reviewer's
>>>>> statement of oversight" is for patch as in "entire patch" meaning:
>>>>>
>>>>> (a) I have carried out a technical review of this patch to
>>>>> evaluate its appropriateness and readiness for inclusion into
>>>>> the mainline kernel.
>>>>>
>>>>> The sentence is explicit and complete, meaning it does not allow
>>>>> implicit variations like: "this patch or part of this patch".
>>>>>
>>>>> Reviewing pieces of the patch while ignoring the main part of it, is
>>>>> much closer to Acknowledgment, thus Ack, and "Reviewed-by" credit should
>>>>> not be applicable.
>>>>
>>>> I strongly disagree. It's all explained in the plenty threads you have started
>>>> on the Subject.
>>>>
>>>> TL;DR: As a reviewer for the piece in question I have done my part fully. It's
>>>> not my issue that the piece is bundled into a single patch. We have options:
>>>> 1) ask to split (and review as standalone piece);
>>>> 2) add (partial) Rb with the pointers of what exactly has been reviewed;
>>>> 3) ignore (silent agreement with the respective subsystem maintainer's opinion);
>>>> 4) ...something I forgot?..
>>>>
>>>> (even partial) Rb != Ack.
>>>>
>>>
>>> I fully agree with Andy.
>>>
>>> As the Xen maintainer I often have to look into such rework patches and often
>>> enough especially the Xen specific parts are mentioned in the patch description
>>> as "compile tested only".
>>>
>>> I see a "Reviewed-by: ... # Xen parts" in such cases as a feedback to the author
>>> or committer that they don't have to look into those parts in more detail.
>>>
>>> The value of such a R-b: is more questionable in case of a pure rename of a
>>> function or struct member, of course.
>>>
>>
>> So you don't agree with "Reviewed-by: # subpart"? Sorry, but I have
>> troubles pointing your disagreement arguments to actual patch content.
> I agree that "Reviewed-by: # subpart" is very valuable and should be used
> in cases where the review really adds some value.
>
> It is different to "Acked-by:" and IMHO not interchangeable with it.
The patch does not make them interchangeable. The patch suggest two
choices if the reviewer's statement of oversight does not apply.
So repeating - which part of patch you disagree with? That reviewer's
statement of oversight says something else?
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-11-05 15:54 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
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 [this message]
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=76b98471-ae9b-4ff3-8337-b50d75c4b7de@kernel.org \
--to=krzk@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=corbet@lwn.net \
--cc=jgross@suse.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 \
--cc=wsa+renesas@sang-engineering.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.