Everyone who contributes is required to look at that list, either directly or indirectly via helper scripts. If you don't contribute, then well, it's completely irrelevant to you anyway.
The problem here is that lots of patches are sent to too many people. Same will happen if you CC a mailing list with many subscribers in patches sent to Gerrit[1] or GitHub for a vibrant project. People will just start ignoring those notifications. It’s not about the tool.
1)Requiring the patch be posted online somewhere, not in the email message as an attachment. Criteria could be set, such as "must be via https, and something that will handle the volume of hits without becoming unreachable due to insufficient quota, server resources, or quota." Or set up a patch hosting server. Etc.
2)Dividing the kernel into major categories like every other major open source software project, and having patch lists for those categories. The main list should only be for announcements and discussions that require a broad audience.
> 2)Dividing the kernel into major categories like every other major open source software project, and having patch lists for those categories. The main list should only be for announcements and discussions that require a broad audience.
Uhhhh the linux kernel mailing list is made up of at least a hundred separate mailing lists with development happening on the more specific mailing lists and a focus on maintaining/integration occurring on the more general lists.
No, it's not enough. One of the most important features missing is that kernel developers will want the equivalent of `git range-diff` (i.e. the ability to compare two versions of a single commit which was submitted as part of a batch of commits) in the UX for code review purposes. The lack of this feature makes the entire thing a non-starter, both Github and Gitlab. That said, they have accepted some PRs on GitHub at the past at one point as an experiment IIRC. But no, the current features they want are not there.
The only real practical alternative is probably something like Gerrit, which still probably is missing features they want, or to write their own patch review tool on top of lore.lkml.org and some other infra.
Github PRs do not make it easy for you to sign merge commits. It's possible in gitlab to my knowledge but in github it's a pain in the ass. And github needlessly touches PR commits so that even if you could fast-forward merge/rebase the PR while keeping signatures in tact, github will still regenerate your commits, breaking the hashes and signatures.
GH for sure allows commentary on individual commits (e.g. <https://github.com/torvalds/linux/commit/23816724fdbd47c28bc...>) but they do not automatically roll up to the top-level PR view (since, how would that work with cherry-picks: it shows up in every PR? what if, as is more likely, the line were superseded in a subsequent commit?)
I would love it if Linus took on email, much like he did with source control management and operating systems - built a set of working principles and the community continued that work.
There's one feature of Discord and Slack that I like - no one can fucking talk to me unless I invite them. I'm so sick of communication systems where random people can contact me. Phones are worse, but email is quite bad.
I've just created a new email because the one I've been using for the last 15 years is simply impossible to manage, with the constant, unsolicited spam.
People tend to underestimate the value of a shared source of truth. Email doesn’t have that. You have no way of knowing if your message was even accepted by the remote MTA
Looks like patches@ will be the new linux-kernel@, except that you won't be allowed to subscribe to it from big e-mail providers. Makes some sense, but wouldn't it be a lot simpler to just force every gmail subscriber to digest-mode where they just get a single e-mail per day (or even week/month), and tell them to use separate tools if they want to interact w/ the list?
It seems this kind of thing would be something that Google would be exceptionally well placed to handle, because it's multiple identical copies of the email, which they should be able to store once and be done with it.
