workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: Mark Brown <broonie@kernel.org>, Jakub Kicinski <kuba@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 20:11:56 +0200	[thread overview]
Message-ID: <20240712201156.1413e80e@foz.lan> (raw)
In-Reply-To: <1a30aea2-e8e4-487d-81e4-dda5c1e8665e@linuxfoundation.org>

Em Fri, 12 Jul 2024 09:42:07 -0600
Shuah Khan <skhan@linuxfoundation.org> escreveu:

> On 7/12/24 09:25, Mark Brown wrote:
> > On Fri, Jul 12, 2024 at 07:49:03AM -0700, Jakub Kicinski wrote:
> >   
> >> +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.

True. So what?

> >> 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.  

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.

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.

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.

Regards,
Mauro

  reply	other threads:[~2024-07-12 18:12 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 [this message]
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
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=20240712201156.1413e80e@foz.lan \
    --to=mchehab@kernel.org \
    --cc=broonie@kernel.org \
    --cc=corbet@lwn.net \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.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