Reducing patch postings to Linux-kernel | Hacker News Reader

Reducing patch postings to Linux-kernel

lwn.net

77 pointsdezgeg32 comments

I don't think I've ever looked at Maintainers before today. "THE REST" is how I'd like my team to remember me. https://www.kernel.org/doc/linux/MAINTAINERS

I've never looked at that list before either. How interesting.

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.

I always wondered how managing patches/patchsets using mail could scale. Now we know: It does not.

I believe this calls not for a separate mailing list but a proper solution, whatever that might be.

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]: Speaking as a Gerrit fan.

The problem would be easily solved by:

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.

Did you expect a HN commenter to actually research the thing they're commenting on? :P

Mailing lists are like XML. Whatever the original problem was, you now have two problems.

mailing lists are democratic/agnostic

How is a self-hosted GitLab instance less democratic than e-mail? The only difference between the two is that one is a major PITA to setup as a user.

Isn't the primary and possibly only objection to GitHub PRs just that they don't allow individual commit commenting?

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?)

How are cherry-picks relevant? Cherry-picking creates completely separate and topologically unrelated commits.

GitLab handles comments on commits within MRs pretty well. It still doesn't make it adequate for projects like Linux though.

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.

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's UI is inadequate for some workflows in much smaller projects already, for many different reasons.

Well it has scaled up until now, which is a sign it could fit the scale of almost all software projects.

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.

If it's anything like git, that might finally kill email for good. (and I'd say a happy GOOD RIDDANCE!)

> I'd say a happy GOOD RIDDANCE!

Why? It's vastly more useful to Discord, Slack, etc and highly amenable to automation in ways they are not -- you can even write your own client!

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.

Spam filters are great... even if you have none. "sorry, spam filter ate your mail" is an excuse noone really questions.

It's pretty trivial to set up a list of people allowed into your inbox.

Maybe not with one of those consumer products like aol or gmail, but I mean seriously...!

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

"kill email for good"

Kill it with fire, a protocol that is easily spyable, not ready for our days of mass surveillance.

You can already use Matrix, with all advantages of email plus end-to-end encryption, rooms and more.

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.

I mean, sure if you're ok moving your mailing list to the not-actually-maintained Google Groups, I bet you wouldn't have gmail deliverability issues.

You'd think so, and yet several google group email lists I'm on are routinely flagged by gmail as being spam.

Wonder if this will help reduce the amount of bikeshedding in PRs

Reply on news.ycombinator.com