From: Jakub Kicinski <kuba@kernel.org>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Dan Williams <dan.j.williams@intel.com>,
corbet@lwn.net, workflows@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH] docs: maintainer: discourage taking conversations off-list
Date: Sat, 13 Jul 2024 16:29:11 -0700 [thread overview]
Message-ID: <20240713162911.3973696a@kernel.org> (raw)
In-Reply-To: <20240713180725.32972358@foz.lan>
On Sat, 13 Jul 2024 18:07:25 +0200 Mauro Carvalho Chehab wrote:
> That's basically what I said: such things happen top/down and not at
> developer/maintainer level. Sure having it documented somewhere, on
> some document that management would actually read can be useful on
> discussions, specially when companies hire a third party company to
> help with their upstream process.
>
> The point is: a developer-focused document - or even a submission
> document process won't affect how companies do their inner source
It's not a developer-focused document, Mauro.
I said that the document should *ALSO*, not exclusively inform
contributors that delay tactics and dismissing external contributors
is not okay in Linux.
> development: companies that have internally heavy development teams
> will basically keep running their own internal development cycle,
> being concerned about upstream only when their product managers
> authorize them to publicly disclosure patches.
>
> If the goal is to create a management awareness about how to better
> cope with upstream, then my suggestion is to write a new document
> from scratch [1] focusing specifically on that, containing a list of
> best practices with focus on orienting management inside companies
> about how to deal with developers and maintainers working on
> upstream.
>
> [1] there is a document there already that seems to be focused at
> management style, but it doesn't cover any best practices
> with regards to innersource/upstream:
>
> Documentation/process/management-style.rst
Like multiple members of the TAB I did have a stab at rewriting
management style at some point. It's not easy. Don't let perfect
be the enemy of good.
next prev parent reply other threads:[~2024-07-13 23:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-12 14:49 [PATCH] docs: maintainer: discourage taking conversations off-list 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 [this message]
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=20240713162911.3973696a@kernel.org \
--to=kuba@kernel.org \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.