From: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>,
corbet@lwn.net, laurent.pinchart@ideasonboard.com,
mchehab@kernel.org
Cc: workflows@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH] docs: maintainer: discourage taking conversations off-list
Date: Sat, 13 Jul 2024 09:28:31 -0500 [thread overview]
Message-ID: <70562aa0-a0bc-4a10-a2ef-6ba64245a752@gmail.com> (raw)
In-Reply-To: <20240712144903.392284-1-kuba@kernel.org>
On 7/12/24 09:49, Jakub Kicinski wrote:
> Multiple vendors seem to prefer taking discussions off list, and
> ask contributors to work with them privately rather than just send
> patches to the list. I'd imagine this is because it's hard to fit in
> time for random developers popping up with features to review into
> packed schedule. From what I've seen "work in private" usually means
> someone on the company side will be assigned to handle the interaction,
> possibly months later. In worst case, the person scheduled to help
> the contributor takes over and writes the code themselves.
> This is not how the community is supposed to work.
So this is completely unenforceable, but as Mauro mentioned, it's an
opportunity to talk about this.
For starters, let's be clear about what the kernel community is actually
losing from closed-door discussions. E.g., if a company wants to fix their
driver, and an employee suggests approach A in an internal discussion, but
someone else prefers approach B, which is then shared publicly on the
mailing lists--is the real issue that the community did not get a chance to
learn about approach A? To discuss it, weigh the pros and cons, and share
opinions? If so, we should note that for published patches preceded by an
internal debate, it's encouraged to include some context in the cover
letters about why different approaches were _not_taken.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> CC: workflows@vger.kernel.org
> CC: linux-doc@vger.kernel.org
> ---
> .../maintainer/feature-and-driver-maintainers.rst | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/maintainer/feature-and-driver-maintainers.rst b/Documentation/maintainer/feature-and-driver-maintainers.rst
> index f04cc183e1de..ac7798280201 100644
> --- a/Documentation/maintainer/feature-and-driver-maintainers.rst
> +++ b/Documentation/maintainer/feature-and-driver-maintainers.rst
> @@ -83,6 +83,17 @@ bugs as well, if the report is of reasonable quality or indicates a
> problem that might be severe -- especially if they have *Supported*
> status of the codebase in the MAINTAINERS file.
>
> +Open development
> +----------------
> +
> +Discussions about user reported issues, and development of new code
> +should be conducted in a manner typical for the larger subsystem.
> +It is common for development within a single company to be conducted
> +behind closed doors. However, maintainers must not redirect discussions
> +and development related to the upstream code from the upstream mailing lists
> +to closed forums or private conversations. Reasonable exceptions to this
> +guidance include discussions about security related issues.
> +
> Selecting the maintainer
> ========================
>
Thanks,
Carlos
next prev parent reply other threads:[~2024-07-13 14:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-12 14:49 Jakub Kicinski
2024-07-12 15:06 ` Greg KH
2024-07-12 15:25 ` Mark Brown
2024-07-12 15:42 ` Shuah Khan
2024-07-12 18:11 ` Mauro Carvalho Chehab
2024-07-12 18:19 ` Randy Dunlap
2024-07-12 23:45 ` Jakub Kicinski
2024-07-13 0:00 ` Dan Williams
2024-07-13 0:12 ` Jakub Kicinski
2024-07-13 7:43 ` Mauro Carvalho Chehab
2024-07-12 18:43 ` Dan Williams
2024-07-13 0:05 ` Jakub Kicinski
2024-07-13 1:18 ` Dan Williams
2024-07-13 8:13 ` Mauro Carvalho Chehab
2024-07-13 14:19 ` Laurent Pinchart
2024-07-13 16:07 ` Mauro Carvalho Chehab
2024-07-13 23:29 ` Jakub Kicinski
2024-07-15 13:29 ` Mark Brown
2024-07-13 14:26 ` Laurent Pinchart
2024-07-13 23:23 ` Jakub Kicinski
2024-07-13 14:28 ` Carlos Bilbao [this message]
2024-07-13 16:25 ` Mauro Carvalho Chehab
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=70562aa0-a0bc-4a10-a2ef-6ba64245a752@gmail.com \
--to=carlos.bilbao.osdev@gmail.com \
--cc=corbet@lwn.net \
--cc=kuba@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-doc@vger.kernel.org \
--cc=mchehab@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