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] [day] [month] [year] [list]
Message-ID: <20230719113622.27afb5f0@kernel.org>
Date: Wed, 19 Jul 2023 11:36:22 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Rob Herring <robh@...nel.org>
Cc: corbet@....net, workflows@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
 gregkh@...uxfoundation.org, linux@...mhuis.info, broonie@...nel.org,
 krzk@...nel.org
Subject: Re: [PATCH docs v2] docs: maintainer: document expectations of
 small time maintainers

On Wed, 19 Jul 2023 11:54:53 -0600 Rob Herring wrote:
> > We appear to have a gap in our process docs. We go into detail
> > on how to contribute code to the kernel, and how to be a subsystem
> > maintainer. I can't find any docs directed towards the thousands
> > of small scale maintainers, like folks maintaining a single driver
> > or a single network protocol.  
> 
> I think the split is great. It would be even better if this
> distinction could be made in MAINTAINERS and then the tools could use
> that. For example, on treewide changes on Cc subsystem maintainers and
> skip driver maintainers. The problem right now is Cc'ing everyone
> quickly hits maillist moderation for too many recipients.

Interesting idea. I wonder how much of this can be accomplished by
improvements to get_maintainers and interpreting what we already have.
There are inverse annoyances, too, where patches for subsystems get
CCed all the way up the hierarchy and including linux-kernel@
for not apparent reason. We have to go sprinkle X: entries in
MAINTAINERS currently to prevent it.

In any case, I think that's a bit tangential. I sent a v3 already
'cause people kept reporting the same typoes :)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ