lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250102094105.GD554@pendragon.ideasonboard.com>
Date: Thu, 2 Jan 2025 11:41:05 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: yuji2.ishikawa@...hiba.co.jp, mchehab@...nel.org, robh@...nel.org,
	krzk+dt@...nel.org, conor+dt@...nel.org,
	sakari.ailus@...ux.intel.com, hverkuil-cisco@...all.nl,
	nobuhiro1.iwamatsu@...hiba.co.jp, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	devicetree@...r.kernel.org
Subject: Re: [PATCH v12 2/8] dt-bindings: media: platform: visconti: Add
 Toshiba Visconti Video Input Interface

On Tue, Dec 17, 2024 at 01:51:54PM +0100, Krzysztof Kozlowski wrote:
> On 17/12/2024 10:45, Laurent Pinchart wrote:
> > On Tue, Dec 17, 2024 at 06:43:22AM +0100, Krzysztof Kozlowski wrote:
> >> On 17/12/2024 01:00, yuji2.ishikawa@...hiba.co.jp wrote:
> >>> Hello Krzysztof
> >>>
> >>> Thank you for your review
> >>>
> >>>> -----Original Message-----
> >>>> From: Krzysztof Kozlowski <krzk@...nel.org>
> >>>> Sent: Monday, November 25, 2024 7:08 PM
> >>>> To: ishikawa yuji(石川 悠司 ○RDC□AITC○EA開)
> >>>> <yuji2.ishikawa@...hiba.co.jp>; Laurent Pinchart
> >>>> <laurent.pinchart@...asonboard.com>; Mauro Carvalho Chehab
> >>>> <mchehab@...nel.org>; Rob Herring <robh@...nel.org>; Krzysztof Kozlowski
> >>>> <krzk+dt@...nel.org>; Conor Dooley <conor+dt@...nel.org>; Sakari Ailus
> >>>> <sakari.ailus@...ux.intel.com>; Hans Verkuil <hverkuil-cisco@...all.nl>;
> >>>> iwamatsu nobuhiro(岩松 信洋 ○DITC□DIT○OST)
> >>>> <nobuhiro1.iwamatsu@...hiba.co.jp>
> >>>> Cc: linux-media@...r.kernel.org; linux-kernel@...r.kernel.org;
> >>>> linux-arm-kernel@...ts.infradead.org; devicetree@...r.kernel.org
> >>>> Subject: Re: [PATCH v12 2/8] dt-bindings: media: platform: visconti: Add
> >>>> Toshiba Visconti Video Input Interface
> >>>>
> >>>> On 25/11/2024 10:21, Yuji Ishikawa wrote:
> >>>>> Adds the Device Tree binding documentation that allows to describe the
> >>>>> Video Input Interface found in Toshiba Visconti SoCs.
> >>>>>
> >>>>> Signed-off-by: Yuji Ishikawa <yuji2.ishikawa@...hiba.co.jp>
> >>>>> Reviewed-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...hiba.co.jp>
> >>>>
> >>>> Why this tag stayed and other was removed? What was the reason of tag
> >>>> removal?
> >>>>
> >>>
> >>> The stayed tag is due to internal review.
> >>
> >> Did the internal review really happened? How is it that immediately new
> >> version has internal review without any traces?
> >>
> >> I have doubts this review happened in the context of reviewer's
> >> statement of oversight.
> >>
> >>> The removed tag is due to code's change (split of csi2rx part) after the last review.
> >>> If the code is largely changed following the instruction of another reviewer
> >>> after obtaining the tags, how should the tags be handled?
> >>
> >> Drop all reviews and perform reviews on the list.
> >>
> >> Such internal review appearing afterwards is rather a proof it you are
> >> adding just the tags to satisfy your process. I have no way to even
> >> verify whether that person performed any reasonable review or maybe just
> >> acked your patch.
> > 
> > How do you verify that for public reviews ?
> 
> By quality or amount of comments. Or timing. Or reviewing cover letter
> without any feedback on individual patches.
> 
> There are many, many ways. Considering how many companies were adding
> fake manager-review-tags in the past (or fake SoBs), I am pretty picky
> on that.

On the other hand I've heard numerous complains about patches being sent
by new developers from large companies to upstream lists without first
being reviewed internally by more experienced developers. You can't ask
people to review patches internally before submitting them upstream and
at the same time complain about R-b tags coming from internal reviews.

The value of a R-b tag, regardless of whether or not it comes from an
internal review, ultimately depends on the trust you have on the
reviewer. You can take that into account to decide when you consider a
patch to be ready to be merged, or to skip reviewing it if enough
reviewers you trust have looked at it first.

-- 
Regards,

Laurent Pinchart

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ