5 ms·

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

by gitgud 5y ago

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 https://lore.kernel.org/lkml/YdIfz+LMewetSaEB@gmail.com/T/#u

srcreigh 5y ago
The submitted link should be changed to this, imo.
- fouc 5y ago
  It's directly linked in the article anyways
aero-glide2 5y ago
>similiar to a pull request. Someone should make a tool which parses mailing lists and presents it in a Github-like frontend
- yhorawu8 5y ago
  Aerc is built around git+email flow: https://aerc-mail.org/ https://aerc-mail.org/
- db48x 5y ago
  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.
  - aero-glide2 5y ago
    Could be read-only. Mailing lists aren't very accessible.
    - MayeulC 5y ago
      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/ https://patchwork.kernel.org/
  - ninkendo 5y ago
    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.
    - db48x 5y ago
      It cuts costs. Server time to render out a large diff is expensive.
      - ninkendo 5y ago
        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."
        db48x 5y ago
        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.
- loeg 5y ago
  There’s patchwork, although I can’t find this submission in it.
- tristan957 5y ago
  https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/27721 https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/27721 SourceHut does this since it exclusively uses mailing lists.
jessaustin 5y ago
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...
- jpgvm 5y ago
  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!
- 41b696ef1113 5y ago
  The guy busted his ass for a year+. Almost any knee jerk response feels trite without appropriate due diligence?
- egberts 5y ago
  How can We respond if We are allbusy building his branch before we can meaningfully respond in kind.
  - denton-scratch 5y ago
    But his branch builds 70% faster now!
- InfiniteRand 5y ago
  First reply came after 12 hours or so
milofeynman 5y ago
Incredibly readable too!
cesarb 5y ago
> (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".

by gitgud 5y ago

srcreigh 5y ago

The submitted link should be changed to this, imo.

fouc 5y ago
It's directly linked in the article anyways

aero-glide2 5y ago

>similiar to a pull request. Someone should make a tool which parses mailing lists and presents it in a Github-like frontend

yhorawu8 5y ago
Aerc is built around git+email flow: https://aerc-mail.org/ https://aerc-mail.org/
db48x 5y ago
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.
- aero-glide2 5y ago
  Could be read-only. Mailing lists aren't very accessible.
  - MayeulC 5y ago
    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/ https://patchwork.kernel.org/
- ninkendo 5y ago
  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.
  - db48x 5y ago
    It cuts costs. Server time to render out a large diff is expensive.
    - ninkendo 5y ago
      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."
      - db48x 5y ago
        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.
loeg 5y ago
There’s patchwork, although I can’t find this submission in it.
tristan957 5y ago
https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/27721 https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/27721 SourceHut does this since it exclusively uses mailing lists.

jessaustin 5y ago

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...

jpgvm 5y ago
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!
41b696ef1113 5y ago
The guy busted his ass for a year+. Almost any knee jerk response feels trite without appropriate due diligence?
egberts 5y ago
How can We respond if We are allbusy building his branch before we can meaningfully respond in kind.
- denton-scratch 5y ago
  But his branch builds 70% faster now!
InfiniteRand 5y ago
First reply came after 12 hours or so

milofeynman 5y ago

Incredibly readable too!

cesarb 5y ago

> (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".