netdev - Re: [PATCH net] net/mlx5: Fill out devlink dev info only for PFs

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: <20250306113914.036e75ea@kernel.org>
Date: Thu, 6 Mar 2025 11:39:14 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Tariq Toukan <ttoukan.linux@...il.com>
Cc: Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
 davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
 saeedm@...dia.com, leon@...nel.org, tariqt@...dia.com,
 andrew+netdev@...n.ch, Gal Pressman <gal@...dia.com>
Subject: Re: [PATCH net] net/mlx5: Fill out devlink dev info only for PFs

On Thu, 6 Mar 2025 21:20:58 +0200 Tariq Toukan wrote:
> On 06/03/2025 4:30, Jakub Kicinski wrote:
> > On Wed, 5 Mar 2025 20:55:15 +0200 Tariq Toukan wrote:  
> >> Reviewed-by: Tariq Toukan <tariqt@...dia.com>  
> > 
> > Too late, take it via your tree, please.
> > You need to respond within 24h or take the patches.  
> 
> Never heard of a 24h rule. Not clear to me what rule you're talking 
> about, what's the rationale behind it, and where it's coming from.
> 
> It's pretty obvious for everyone that responding within 24h cannot be 
> committed, and is not always achievable.
> 
> Moreover, this contradicts with maintainer-netdev.rst, which explicitly 
> aligns the expected review timeline to be 48h for triage, also to give 
> the opportunity for more reviewers to share their thoughts.

Quoting documentation:

  Responsibilities
  ================

  The amount of maintenance work is usually proportional to the size
  and popularity of the code base. Small features and drivers should
  require relatively small amount of care and feeding. Nonetheless
  when the work does arrive (in form of patches which need review,
  user bug reports etc.) it has to be acted upon promptly.
  Even when a particular driver only sees one patch a month, or a quarter,
  a subsystem could well have a hundred such drivers. Subsystem
  maintainers cannot afford to wait a long time to hear from reviewers.

  The exact expectations on the response time will vary by subsystem.
  The patch review SLA the subsystem had set for itself can sometimes
  be found in the subsystem documentation. Failing that as a rule of thumb
  reviewers should try to respond quicker than what is the usual patch
  review delay of the subsystem maintainer. The resulting expectations
  may range from two working days for fast-paced subsystems (e.g. networking)
  to as long as a few weeks in slower moving parts of the kernel.

See: https://www.kernel.org/doc/html/next/maintainer/feature-and-driver-maintainers.html#responsibilities