Re: PSA: generic patches@xxxxxxxxxxxxxxx list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Tue, Nov 30, 2021 at 12:56 AM Konstantin Ryabitsev
<konstantin@xxxxxxxxxxxxxxxxxxx> wrote:
> Hi, all:
> We have a generically named list `patches@xxxxxxxxxxxxxxx` 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@xxxxxxxxxxxxxxx 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 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 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@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx 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,


[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux