Re: [PATCH v2] docs: submitting-patches: Clarify half-baked review tags

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Thu, Nov 05, 2026 at 10:12:00AM +0100, Krzysztof Kozlowski wrote:
> On 05/11/2026 10:06, Wolfram Sang wrote:
> > 
> >> Reviewed-by even with the "# subpart" still appears in person's credits
> >> and reviewing entire patch of 700 lines of diff code (like Frank's SPI
> >> patch) is not the same as 10 diff codes for one driver.
> > 
> > Yes, if you want to spoil that, you'd need to introduce
> > 
> > 	Partly-reviewed-by: ...
> > 
> > or something.
> 
> Ack is for that, no need for a new tag, quoting:
> 
> "Acked-by.... user may not have carried out a technical review of the
> patch, yet they may be satisfied ..."
> 
> "Reviewed-by:, instead, indicates that *the patch* has been reviewed and
> found acceptable according to the Reviewer's Statement:"
> 
> Note that there is little sense in reviewing - as in statement of
> oversight credit review - pieces of patch in context I discuss here,
> e.g. one big complex rework combined with updates of drivers. Who cares
> about the drivers? The complex rework is important and should be
> reviewed, but people skip bigger picture and put their stamp of approval.

Nice, and what as a particular piece maintainer I should do if somebody
created some helper somewhere (not Cc'ing me), waited to a cycle and started
cleaning up or refactor the drivers based on that API? Basically I was stand
in front of a fact, I may tell NAK to that, but what should we do if half of
the kernel will use new API, half will use old one due to disagreements on
implementation, naming, et cetera? Rb in this sense tells that I have reviewed
the refactoring part that has been done on a piece that I'm in charge for and
it looks good. Breaking the flow or behaviour might have been done on the
upper layer for a bigger number of users.

> Stamp of approval is Ack, no need to mix it with reviewer's statement of
> oversight.

-- 
With Best Regards,
Andy Shevchenko