Hacker News Reader

Comment by fuzzy2 | Hacker News Reader

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

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

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.

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.

Reply on news.ycombinator.com