linux-kernel - Re: [PATCH docs v3] docs: maintainer: document expectations of small time maintainers

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: <20230720-proxy-smile-f1b882906ded@spud>
Date:   Thu, 20 Jul 2023 16:15:26 +0100
From:   Conor Dooley <conor@...nel.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     corbet@....net, Andrew Lunn <andrew@...n.ch>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Mark Brown <broonie@...nel.org>,
        Leon Romanovsky <leonro@...dia.com>, workflows@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, linux@...mhuis.info, kvalo@...nel.org,
        benjamin.poirier@...il.com
Subject: Re: [PATCH docs v3] docs: maintainer: document expectations of small
 time maintainers

Hey,

On Wed, Jul 19, 2023 at 11:32:25AM -0700, Jakub Kicinski 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.
> 
> Document our expectations and best practices. I'm hoping this doc
> will be particularly useful to set expectations with HW vendors.

Thanks for writing this up, it's great to have this stuff written down.

I had one minor comment from reading through things...

> +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.
> +
> +Mailing list participation
> +--------------------------

> +Reviews
> +-------

> +Refactoring and core changes
> +----------------------------


> +Bug reports
> +-----------

..I noticed that none of these sections address actually testing the
code they're responsible for on a (semi-)regular basis. Sure, that comes
as part of reviewing the patches for their code, but changes to other
subsystems that a driver/feature maintainer probably would not have been
CCed on may cause problems for the code they maintain.
If we are adding a doc about best-practice for maintainers, I think we
should be encouraging people to test regularly.


Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)