From: Jakub Kicinski <kuba@kernel.org>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Shuah Khan <skhan@linuxfoundation.org>,
Mark Brown <broonie@kernel.org>,
corbet@lwn.net, workflows@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH] docs: maintainer: discourage taking conversations off-list
Date: Fri, 12 Jul 2024 16:45:04 -0700 [thread overview]
Message-ID: <20240712164504.76b15e31@kernel.org> (raw)
In-Reply-To: <20240712201156.1413e80e@foz.lan>
On Fri, 12 Jul 2024 20:11:56 +0200 Mauro Carvalho Chehab wrote:
> Not sure what this somewhat obscure message wants to accomplish.
>
> It is quite common to have developers and maintainers discussing
> outside public forums and internally at the companies they're working
> for. There are lots of reasonable exceptions besides security. On my
> years of experience, the reasons I've seen more often are:
>
> 1. language and/or cultural barriers;
> 2. teaching and mentoring new developers to start contributing upstream;
> 3. need to have internal discussions in the light of some IP protected
> material.
>
> (1) and (2) are very common for non-native English speakers
> and for newbies, and we do want to have more contributions from
> them. (3) is unavoidable, as discussions related to protected
> IP can't be disclosed due to legal reasons.
Those are valid points but I don't know how to weave them in without
losing clarity. The goal is also to call out such behavior to
_contributors_, so that they know they can reach out to more senior
maintainers if it happens to them. We don't know when discussion is
taken private (by definition). Otherwise contributors get mistreated
by some corpo-maintainer and they turn away from Linux :(
> Also, if you take it to the letter, have discussions on LPC,
> summits BoFs, other events handled by the open source community
> and wall conversations are "closed forums/private conversations".
> I've seen a lot of good results produced on such private
> conversations that solved relevant conflicts and got
> materialized as great contributions.
>
> There's nothing wrong with that, provided that the outcoming of
> such internal discussions are reflected publicly as patches,
> summit minutes, LWN articles, etc.
Would it help if we speak of "open forums" instead of mailing list?
I think LPC including "hallway track" fall squarely under "conducted
in a manner typical for the larger subsystem." Here's slightly edited
version:
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, development and discussions initiated
by community members must not be redirected from public to closed forums
or to private email conversations. Reasonable exceptions to this guidance
include discussions about security related issues.
> The only issues I see with such talks is that the work when
> co-authored should be properly marked as such and that
> reviewews/acks taken behind doors don't have the same meaning
> as an upstream review, as they may be due to some internal
> formalities.
>
> IMO, the best would instead to give a positive message. E. g.
> something like:
>
> Maintainers must encourage discussions and reviews to happen
> at public mailing lists, avoiding whenever possible to have
> internal discussions.
That's not the message, tho. If someone emails a company privately
that's fine. If company has internal processes for its development -
also fine (as explicitly called out). I'm trying to set the baseline,
not describe the ideal world.
I am specifically calling out that if someone submits a patch, or
reports a regression the correct response is to review it on the list.
Like a normal person.
Not reply privately that "it's on the company roadmap, just wait" :|
Or reply with a patch company has "forgotten to upstream"..
Maybe it's a cultural thing, but to me this is where the relentless
positivity is counter-productive. I don't want to encourage people
to be angles. I want them not to do the shitty thing.
next prev parent reply other threads:[~2024-07-12 23:45 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 [this message]
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
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=20240712164504.76b15e31@kernel.org \
--to=kuba@kernel.org \
--cc=broonie@kernel.org \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=skhan@linuxfoundation.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