Hacker News Reader

Comment by gitgud | Hacker News Reader

Here's the [1] patch cover letter sent to Linus Torvalds (similar to a Pull Request I suppose)

[1] https://lore.kernel.org/lkml/YdIfz+LMewetSaEB@gmail.com/T/#u

> (similar to a Pull Request I suppose)

It's not "similar to a pull request", it is a pull request (or would be if this wasn't a RFC). While this one is a bit different than usual (he didn't post the full diffstat, for instance), that's the way pull requests were traditionally done, even before github/gitlab/etc existed. A traditional pull request is an email which besides the description says something like "please pull from git://... some-branch", and notice that this one has near the top "[...] which can be found here: git://git.kernel.org/pub/scm/linux/kernel/git/mingo/tip.git master". The maintainer pastes these two arguments (the URL and the branch) to a "git pull" command line, so in this case it would be "git pull git://git.kernel.org/pub/scm/linux/kernel/git/mingo/tip.git master".

>similiar to a pull request.

Someone should make a tool which parses mailing lists and presents it in a Github-like frontend

Aerc is built around git+email flow: https://aerc-mail.org/

Why? Github and similar front–ends top out at a few dozen commits or comments on a merge request before they start whining that the change is too big.

Could be read-only. Mailing lists aren't very accessible.

It depends on your definition of accessible. This is the tool kernel devs use, and that patch is intended for them. It's mostly a matter of getting used to it.

Github's user interface was scary at first for me, much more than a plain-text mail. So was GitLab.

Some people I know have complained to me that I send plain-text mails and that nobody wants to read a wall of text. I think that's probably a user issue, and it can in turn help filter low-effort comments.

If talking about a11y, plaintext mail ought to be one of the most accessible formats: high-contrast, can be processed by multiple tools including screen readers. ASCII art trough screenreaders is probably an exception.

-----

Now, about your specific question: there's patchwork[1], though I don't think that instance covers the general LKML.

[1] https://patchwork.kernel.org/

Absolutely nothing about GitHub infuriates me more than this “feature”… “large diffs are not rendered by default”.

Why does GitHub ignore the most important thing to look at in a PR? It’s not the tiny changes that are of top importance, it’s the big ones. The number of times I’ve been burned by trying to ctrl+f for something I’m looking for in someone’s PR (trying to see “does this diff touch X” for instance) — and getting a false impression of the code I’m reviewing — just because GitHub silently elided showing a big diff somewhere in the middle of a PR… is too high to count.

The single most important part of GitHub is the social aspect (code reviews), and it’s the part it is objectively worst at. If I just wanted to host my code, I could make a simple server with SSH accounts and let people push to it. We use GitHub because it’s supposed to be a venue for discussing complex changes, and it sucks by default at discussing complex changes.

It cuts costs. Server time to render out a large diff is expensive.

I use a GitHub enterprise instance, and we have enough server power to spare. There's no option to say "we have the server capacity, please render large diffs."

They probably didn’t tell the engineers who designed and implemented it that it was a cost–cutting measure. But even if they did, every option or preference that you add to your software multiplies the number of cases that you have to test. In principle a boolean option doubles the number of tests you need to do, because you have to run all of your tests with it off and all of them again with it on. Of course in practice people usually just assume that there won’t be any unwanted interactions between most of these type of options, which is often true enough. It is quite common to limit the number of such options in order to control costs over the long term. It reduces development, QA, maintenance, installation, and support costs. On the other hand, it does annoy users.

There’s patchwork, although I can’t find this submission in it.

https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/27721

SourceHut does this since it exclusively uses mailing lists.

The submitted link should be changed to this, imo.

It's directly linked in the article anyways

Is it interesting that now, nearly eight hours later, there are still no replies on the list? Is every relevant developer really going to wait to reply until after they understand this patch series? That seems very effective...

Everyone that is capable of reviewing this effectively is likely on leave right now.

Almost all the core maintainers are employed only to work on the kernel 9-5 outside of extraordinary situations (say a critical privesc or RCE in the kernel).

This patch set will not be ignored but it likely also won't receive review until everyone is back behind keyboards in the coming days.

Kernel devs enjoy the holiday season too!

The guy busted his ass for a year+. Almost any knee jerk response feels trite without appropriate due diligence?

How can We respond if We are allbusy building his branch before we can meaningfully respond in kind.

But his branch builds 70% faster now!

First reply came after 12 hours or so

Incredibly readable too!

Reply on news.ycombinator.com