workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Edward Cree <ecree.xilinx@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>, corbet@lwn.net
Cc: Andrew Lunn <andrew@lunn.ch>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Mark Brown <broonie@kernel.org>,
	Leon Romanovsky <leonro@nvidia.com>,
	workflows@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	linux@leemhuis.info, kvalo@kernel.org,
	benjamin.poirier@gmail.com
Subject: Re: [PATCH docs v3] docs: maintainer: document expectations of small time maintainers
Date: Thu, 20 Jul 2023 19:23:56 +0100	[thread overview]
Message-ID: <50164116-9d12-698d-f552-96b52c718749@gmail.com> (raw)
In-Reply-To: <20230719183225.1827100-1-kuba@kernel.org>

On 19/07/2023 19:32, 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.
> 
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reviewed-by: Mark Brown <broonie@kernel.org>
> Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---

Thanks for writing this.  One question—

> +Reviews
> +-------
> +
> +Maintainers must review *all* patches touching exclusively their drivers,
> +no matter how trivial. If the patch is a tree wide change and modifies
> +multiple drivers - whether to provide a review is left to the maintainer.

Does this apply even to "checkpatch cleanup patch spam", where other patches
 sprayed from the same source (perhaps against other drivers) have already
 been nacked as worthless churn?  I've generally been assuming I can ignore
 those, do I need to make sure to explicitly respond with typically a repeat
 of what's already been said elsewhere?

-ed

  parent reply	other threads:[~2023-07-20 18:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-19 18:32 Jakub Kicinski
2023-07-20 15:15 ` Conor Dooley
2023-07-20 21:37   ` Jakub Kicinski
2023-07-20 22:23     ` Conor Dooley
2023-07-20 18:23 ` Edward Cree [this message]
2023-07-20 18:26   ` Greg Kroah-Hartman
2023-07-20 18:31   ` Mark Brown
2023-07-20 21:42   ` Jakub Kicinski
2023-07-21  7:46 ` Martin Habets
2023-07-21  8:38 ` Simon Horman
2023-07-21 19:53 ` Jonathan Corbet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50164116-9d12-698d-f552-96b52c718749@gmail.com \
    --to=ecree.xilinx@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=benjamin.poirier@gmail.com \
    --cc=broonie@kernel.org \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=krzk@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kvalo@kernel.org \
    --cc=leonro@nvidia.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@leemhuis.info \
    --cc=netdev@vger.kernel.org \
    --cc=workflows@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox