4 ms·

> I just wish they moved away from email as the only way of contributing. What alternative do you suggest, and in what way is it better than email? > It doesn

by adwn 5y ago

> I just wish they moved away from email as the only way of contributing. What alternative do you suggest, and in what way is it better than email? > It doesn't really scale well [...] There are few things that scale better than email... > [...] doesn't make contributing for newbies easier. That's a good thing: If you haven't even mastered sending a plaintext email, I really wouldn't expect you to be able to constructively contribute to kernel development. Feel free to experiment with your local copy, though – it's open source after all.

jorvi 5y ago
I do think committing via Github would significantly lower the friction of contributing to the Linux kernel for a chunk of the developer population, and there might actually be a decent well of untapped potential there. Of course there will also be a lot of pull request noise, so I can't say if that tradeoff is ultimately worth it. Edit: well I guess OSS people are extremely hostile to even the discussion of more people contributing to the Linux kernel. My bad.
- adwn 5y ago
  > committing via Github [...] there might actually be a decent well of untapped potential there I don't buy it. Contributing to the Linux kernel is inherently non-trivial, and I find it completely implausible that any non-negligible number of developers are able to do that while not knowing how to send a mail. Seriously, what's the scenario supposed to be here? "I've found a bug in low-level C code, and it's not a false positive, and I fixed and tested it, and I've looked up and followed the kernel coding guidelines, but I don't know how/am too lazy to send a patch per mail"?
  - u801e 5y ago
    > don't know how/am too lazy to send a patch per mail"? Arguably, it's even easier to do so with git format-patch and send-email commands, since they address the issue of MUAs mangling the patch before sending it to the mailing list.
- uncomputation 5y ago
  It’s not hostility per se, it’s gate keeping/admission. Linux is arguably the greatest OSS ever made and jumping the gun to whatever’s the next trend (GitHub has only been around for ten years) is just unwise. Shiny object syndrome. What happens when GitHub is down and the thousands of projects that depend on Linux (device drivers, networking stacks, soc’s for instance) can no longer access it? Why don’t we just move LWN to Notion? And we can use React 17.8b for the man pages! /s Also GitHub is owned by Microsoft and I hope I don’t need to explain why Linux-users wouldn’t be comfortable with that…
bitcharmer 5y ago
> If you haven't even mastered sending a plaintext email Surprise, I've had a few of my patches accepted and this statement is just thinly veiled insult, if I ever saw one. Have you ever heard of pull requests? Pull requests are 10x easier than adhering to lkml's email rituals.
- diegocg 5y ago
  Git pull requests were invented by the Linux people and they were invented in a context of people sending mails
  - u801e 5y ago
    Git even has a command for that called request-pull[1]. [1] https://git-scm.com/docs/git-request-pull https://git-scm.com/docs/git-request-pull
- u801e 5y ago
  Assuming you have your git config set up to use git format-patch and git send-email, they're pretty easy to use. Plus keeping your local copy of the git repo up to date is easier than keeping your github fork up to date.
tester756 5y ago
I always wondered - how do people read those emails? in just plain text with no colors for code? it must be painful as hell
- boomlinde 5y ago
  Just apply the patch and use your favorite diff tool.
- u801e 5y ago
  It depends on the email client. Some of them have syntax highlighting and tools to navigate the diff.
williamdclt 5y ago
> If you haven't even mastered sending a plaintext email, , I really wouldn't expect you to be able to constructively contribute to kernel development. That's entirely BS. To contribute to these projects (my experience is contributing to Git), you need to respect a dozen conventions that seem to come from another age. Just subscribing to the mailing list is not trivial for somebody in their twenties that never had to do something like that: it's the sort of things that's easy in retrospect, but the UX is hard to discover and the lack of parallel with other tools we regularly use (such mailing lists aren't a thing that most devs use) adds a huge amount of friction. And then you need to find somewhere that explain the conventions to try and contribute and figure out how to configure your email client, how to get a patch for your commits, how to insert your patch in your email, how to write an acceptable email subject and an acceptable email body and how it relates to your commit message, who you should CC, how to handle multi-commits contributions, how to answer emails (while respecting another half-dozen conventions)... It's not impossible, but there's a dozen things you need to figure out, half of them you don't even _know_ you need to figure out, so it's a lot of friction. This friction might be a good thing (that's another debate), but saying "you just need to be able to send a plaintext email" is completely false and dismissive.
- adwn 5y ago
  > It's not impossible, but there's a dozen things you need to figure out [...] Most of those things don't go away if you send a pull request via the Github web interface, because they boil down to "follow the rules and guidelines of the Linux kernel developers". Oh, and not everyone is intimately familiar with the Github pull request interfaces.
- u801e 5y ago
  > That's entirely BS. To contribute to these projects (my experience is contributing to Git), you need to respect a dozen conventions that seem to come from another age. Just subscribing to the mailing list is not trivial for somebody in their twenties that never had to do something like that This belief that people aren't able to figure out things on their own is the problem. You're basically telling people that it's hard and they'll never figure it out. You're telling people that there are so many things they need to do that they'll never be able to do them. Have you ever considered that these statements themselves are ones that drive away potential contributors? Why not let people make their own judgment about the process after they've gone through it instead of adding your own bias to it? > And then you need to find somewhere that explain the conventions to try and contribute and figure out how to configure your email client, how to get a patch for your commits, how to insert your patch in your email, how to write an acceptable email subject and an acceptable email body and how it relates to your commit message, who you should CC, how to handle multi-commits contributions, how to answer emails (while respecting another half-dozen conventions) This is all described in the submitting patches[1] document in the source tree. It even links to an interactive tutorial regarding how to set up git-send-email[2] [1] https://github.com/torvalds/linux/blob/master/Documentation/process/submitting-patches.rst https://github.com/torvalds/linux/blob/master/Documentation/... [2] https://git-send-email.io/ https://git-send-email.io/

by adwn 5y ago

jorvi 5y ago

I do think committing via Github would significantly lower the friction of contributing to the Linux kernel for a chunk of the developer population, and there might actually be a decent well of untapped potential there. Of course there will also be a lot of pull request noise, so I can't say if that tradeoff is ultimately worth it. Edit: well I guess OSS people are extremely hostile to even the discussion of more people contributing to the Linux kernel. My bad.

adwn 5y ago
> committing via Github [...] there might actually be a decent well of untapped potential there I don't buy it. Contributing to the Linux kernel is inherently non-trivial, and I find it completely implausible that any non-negligible number of developers are able to do that while not knowing how to send a mail. Seriously, what's the scenario supposed to be here? "I've found a bug in low-level C code, and it's not a false positive, and I fixed and tested it, and I've looked up and followed the kernel coding guidelines, but I don't know how/am too lazy to send a patch per mail"?
- u801e 5y ago
  > don't know how/am too lazy to send a patch per mail"? Arguably, it's even easier to do so with git format-patch and send-email commands, since they address the issue of MUAs mangling the patch before sending it to the mailing list.
uncomputation 5y ago
It’s not hostility per se, it’s gate keeping/admission. Linux is arguably the greatest OSS ever made and jumping the gun to whatever’s the next trend (GitHub has only been around for ten years) is just unwise. Shiny object syndrome. What happens when GitHub is down and the thousands of projects that depend on Linux (device drivers, networking stacks, soc’s for instance) can no longer access it? Why don’t we just move LWN to Notion? And we can use React 17.8b for the man pages! /s Also GitHub is owned by Microsoft and I hope I don’t need to explain why Linux-users wouldn’t be comfortable with that…

bitcharmer 5y ago

> If you haven't even mastered sending a plaintext email Surprise, I've had a few of my patches accepted and this statement is just thinly veiled insult, if I ever saw one. Have you ever heard of pull requests? Pull requests are 10x easier than adhering to lkml's email rituals.

diegocg 5y ago
Git pull requests were invented by the Linux people and they were invented in a context of people sending mails
- u801e 5y ago
  Git even has a command for that called request-pull[1]. [1] https://git-scm.com/docs/git-request-pull https://git-scm.com/docs/git-request-pull
u801e 5y ago
Assuming you have your git config set up to use git format-patch and git send-email, they're pretty easy to use. Plus keeping your local copy of the git repo up to date is easier than keeping your github fork up to date.

tester756 5y ago

I always wondered - how do people read those emails? in just plain text with no colors for code? it must be painful as hell

boomlinde 5y ago
Just apply the patch and use your favorite diff tool.
u801e 5y ago
It depends on the email client. Some of them have syntax highlighting and tools to navigate the diff.

williamdclt 5y ago

> If you haven't even mastered sending a plaintext email, , I really wouldn't expect you to be able to constructively contribute to kernel development. That's entirely BS. To contribute to these projects (my experience is contributing to Git), you need to respect a dozen conventions that seem to come from another age. Just subscribing to the mailing list is not trivial for somebody in their twenties that never had to do something like that: it's the sort of things that's easy in retrospect, but the UX is hard to discover and the lack of parallel with other tools we regularly use (such mailing lists aren't a thing that most devs use) adds a huge amount of friction. And then you need to find somewhere that explain the conventions to try and contribute and figure out how to configure your email client, how to get a patch for your commits, how to insert your patch in your email, how to write an acceptable email subject and an acceptable email body and how it relates to your commit message, who you should CC, how to handle multi-commits contributions, how to answer emails (while respecting another half-dozen conventions)... It's not impossible, but there's a dozen things you need to figure out, half of them you don't even _know_ you need to figure out, so it's a lot of friction. This friction might be a good thing (that's another debate), but saying "you just need to be able to send a plaintext email" is completely false and dismissive.

adwn 5y ago
> It's not impossible, but there's a dozen things you need to figure out [...] Most of those things don't go away if you send a pull request via the Github web interface, because they boil down to "follow the rules and guidelines of the Linux kernel developers". Oh, and not everyone is intimately familiar with the Github pull request interfaces.
u801e 5y ago
> That's entirely BS. To contribute to these projects (my experience is contributing to Git), you need to respect a dozen conventions that seem to come from another age. Just subscribing to the mailing list is not trivial for somebody in their twenties that never had to do something like that This belief that people aren't able to figure out things on their own is the problem. You're basically telling people that it's hard and they'll never figure it out. You're telling people that there are so many things they need to do that they'll never be able to do them. Have you ever considered that these statements themselves are ones that drive away potential contributors? Why not let people make their own judgment about the process after they've gone through it instead of adding your own bias to it? > And then you need to find somewhere that explain the conventions to try and contribute and figure out how to configure your email client, how to get a patch for your commits, how to insert your patch in your email, how to write an acceptable email subject and an acceptable email body and how it relates to your commit message, who you should CC, how to handle multi-commits contributions, how to answer emails (while respecting another half-dozen conventions) This is all described in the submitting patches[1] document in the source tree. It even links to an interactive tutorial regarding how to set up git-send-email[2] [1] https://github.com/torvalds/linux/blob/master/Documentation/process/submitting-patches.rst https://github.com/torvalds/linux/blob/master/Documentation/... [2] https://git-send-email.io/ https://git-send-email.io/