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 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@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, Lukas
