From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: users@linux.kernel.org, workflows@vger.kernel.org
Subject: Re: PSA: generic patches@lists.linux.dev list
Date: Tue, 30 Nov 2021 02:09:29 +0100 [thread overview]
Message-ID: <CAKXUXMxvm9NQHK9fjtzPFEasRthTdceNLcpwpQ9oV62zpvWtZw@mail.gmail.com> (raw)
In-Reply-To: <20211129215634.gydsyfyhu6rhbbe2@meerkat.local>
On Tue, Nov 30, 2021 at 12:56 AM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Hi, all:
>
> We have a generically named list `patches@lists.linux.dev` that can be used as
> an address for sending patches.
>
> This can be useful for a number of reasons:
>
> 1. those maintainers already using lei [1] can list patches@lists.linux.dev as
> the mailing list address for their subsystem and receive mail sent to it
> via lei saved searches
> 2. mail sent to this address goes to public-inbox first, so it's likely to
> show up on lore.kernel.org very quickly, with fewest delays and omissions
> 3. you can use this address as an extra cc for mail sent to other lists that
> are less likely to preserve the message body as-is -- when retrieving mail
> with b4, it will give priority to the linux.dev address in the presence of
> duplicates.
>
> Mostly, it's a dumping ground for patches. We can even use it as "THE REST"
> address in MAINTAINERS to help offload some of the traffic from vger and make
> linux-kernel@vger.kernel.org less of a firehose and more amenable to actual
> discussions.
>
I always thought that sending patches to mailing lists has the beauty
that the technical discussion and decision on the actual change is
"seamlessly" connected on the same channel and allows simple
transition between those two categories. E.g., a discussion can evolve
into a proposition of a patch within the email thread or a patch can
spin-off a wider discussion on the software architecture or policies
in the development.
The proposition of patches@lists.linux.dev dedicated for patches vs.
other mails somehow is troubling to that beauty.
Also, I would not be surprised if besides the obvious disconnect
caused by two lists and the unclear situation of which email belongs
to which category (when does a technical discussion cause a patch
proposition, or when is a patch review evolving into a policy
discussion), we end up with two mailing lists, patches and
linux-kernel, that both lists still feel like two fire hoses similarly
uncontrollable as before. Or alternatively: any good filtering that
made it manageable before with one large list, would not look
significantly simpler just because there are now two lists with an
implicit categorization on its mail content.
Just thinking out loud,
Lukas
prev parent reply other threads:[~2021-11-30 1:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-29 21:56 PSA: generic patches@lists.linux.dev list Konstantin Ryabitsev
2021-11-30 1:09 ` Lukas Bulwahn [this message]
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=CAKXUXMxvm9NQHK9fjtzPFEasRthTdceNLcpwpQ9oV62zpvWtZw@mail.gmail.com \
--to=lukas.bulwahn@gmail.com \
--cc=konstantin@linuxfoundation.org \
--cc=users@linux.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.