On the radar: what is the linux-kernel mailing list for? @monsieuricon is suggesting that many or most patch postings be redirected to a separate list:

https://lwn.net/ml/ksummit-discuss/20231106-venomous-raccoon-of-wealth-acc57c@nitro/

I've not jumped into the conversation because I'm still trying to figure out what I think about it. I'm one of those people who actually reads over that list; the broad view it provides is helpful in both the LWN and documentation-maintainer roles. But it *is* painful to keep up with.

LKML has traditionally been the place you post patches to get them reviewed. If that's not its role anymore, what is it for?

@corbet @monsieuricon as long as all the posted patches are archived somewhere and can be retrieved later at any time with no hassle (like it is with lore now), there's no difference what name the dumpster gets.

@corbet @monsieuricon

But is LKML still CCed on basically everything? I didn't check, but I got the impression that sometimes it's forgotten or omitted on purpise. If that is frequently the case I wonder if it would make more sense to create some kind of "automatically filled catch all list" that better serves the needs of those that like LKML how it is.

[if anyone things it's worth bringing this point to the discussion let me know]

@corbet @monsieuricon

Side note: I for now decided to stay away from that discussion myself, despite having recently posted something here that goes into a similar direction (or a step further, to be a bit more precise):

https://fosstodon.org/@kernellogger/111350542433445617

@kernellogger @corbet I like the idea of lkml as an aggregation of the other lists but I don't think that alone would solve the problems that @monsieuricon has put forward. Unless it wasn't distributed via email and only available via nntp.lore.kernel.org perhaps...

@kernellogger @corbet Yes, if you use get_maintainer.pl (which is how you're supposed to do it), linux-kernel will *always* be included.

@andyprice @corbet @monsieuricon

yeah, fair point; I have different problems in mind here

@monsieuricon @corbet

For patches, yeah; but I meant for other stuff, like bug reports and things discussed without a patch.

@corbet To highlight the main point I'm trying to make, the problem isn't that linux-kernel receives a lot of mail. It's that it has 3,000 subscribers, which translates into about 3 million individual messages daily on average. This is high enough volume that many email providers start throttling us back.

@kernellogger @corbet @monsieuricon I only CC lkml when:
1. It's the mailing list for the subsystem (e.g. regulator),
2. The subsystem mailing list is rather obscure, or not archived on lore.
3. The patch fixes a serious issue or regression.

@corbet @monsieuricon I'm in the same boat, I like browsing it as an overview. The architecture lists perform a similar function (linux-arm-kernel and linuxppc-dev) but in a more focused form. I'd be disappointed if the proposal gets implemented.

@kernellogger @monsieuricon @corbet People still use get_maintainer for that (often with —file on the relevant driver/subsystem core).

@broonie @monsieuricon @corbet

Sure, but not everyone, which I noticed during my regression tracking work.

See also: https://society.oftrolls.com/@geert/111371010492230622

@geert @corbet @monsieuricon

yeah, make sense (side note: CCing the regressions list on regression would be nice, too). And I got the impression a few people use a similar strategy, but I didn't properly check.

@kernellogger @corbet @monsieuricon Forgot one:
4. I want to increase the probability of making it into LWN.net's Announcements / Kernel patches of interest ;-)

@geert @kernellogger @corbet @monsieuricon I believe choosing manually which list to CC (e.g. to CC LKML or not) is not the way the community should work. It might work for you, but such choice should not be in general task for a human. Scripts should make this decision for you.

This means that, if anyone has to or wants to trim or extend the output of scripts/get_maintainers.pl more than once per month, then the script is doing poor or insufficient job.

P.S. Occasional adjustment of get_maintainers.pl is reasonable, but not on regular basis.

I finally decided to unsubscribe linux-kernel@ and revisit my humble public-inbox-based mail client (https://github.com/sjp38/hackermail).

RE: https://social.kernel.org/objects/a58dbb3c-21f5-47fe-a08d-55e918830fe7

@sj yeah I unsubbed it ages ago, stay subbed to linux-mm and linux-mm-commits only