8 ms·

> The current workflow works fine, and I hardly think any potential kernel hackers are choosing not to work on the kernel because it is email-driven. I'm not s

> The current workflow works fine, and I hardly think any potential kernel hackers are choosing not to work on the kernel because it is email-driven. I'm not so sure. If the kernel development was on Github, I may have looked into contributing, but as it stands, its not worth the trouble to try to contribute (as I don't have anything specific to help with). And, I suspect there are more capable developers who are closer to the edge than me. Anyway, having a slightly lower bar to get started may not get more developers involved, but instead my get them involved more quickly.

chubot 9y ago
Linux is one of the few open source projects to with plenty of developers. They don't need or even want your help, especially if your attitude toward tools is rigid, and if you have nothing concrete to contribute. Linus has said this a few times -- in general they don't actively try to onboard new contributors.
- pmoriarty 9y ago
  "They don't need or even want your help" There was in fact a talk given by Greg Kroah-Hartman, one Linux's lead maintainers, about development for the Linux kernel which he titled "I Don't Want Your Code". https://www.youtube.com/watch?v=fMeH7wqOwXA https://www.youtube.com/watch?v=fMeH7wqOwXA
  - chubot 9y ago
    Haha, thanks for the video. I watched it, and I was surprised to see that it's about a specific company. He's at Linaro, specfically taking their developers to task for sending bad patches. And they indeed sound horrible, but he's good natured about it. I'm just starting to accept patches for my project, and honestly I'm flabberghasted that people will send patches that not only don't run, but don't build. And Greg was saying the same thing. I guess I got spoiled at my last job, where people generally sent high quality patches / code reviews. Although toward the end, I noticed some sloppiness. It wasn't the main reason I left the company, but it started to feel like the downfall... I don't want to work with people who don't know how to submit code reviews / patches.
    - tytso 9y ago
      Linaro isn't a company; it's a "collaborative engineering organization". It does employ some number of engineers, funded by donations by their member companies, but they also accept "in-kind" donations where engineers are detailed to work at Linaro for some period of time. So it wasn't really directed at Linaro per se, but more at the member companies of Linaro.
    - chungy 9y ago
      > I'm just starting to accept patches for my project, and honestly I'm flabberghasted that people will send patches that not only don't run, but don't build. And Greg was saying the same thing. Indeed, I've seen the same thing. I have considered automatically rejecting any patch made with the GitHub online editor (obvious because the committer name is always GitHub). They are pretty much invariably of shit quality.
      - simonh 9y ago
        That's fair enough. The only times I've submitted patches that way is to update documentation files. I'd never submit code that way.
- Someone 9y ago
  So, what's the age distribution of contributors to the main tree, and how does it develop over time? This _might_ show a long-term risk for Linux.
  - wongarsu 9y ago
    80% of the kernel development is done by companies who want their code in the kernel (whether that's because they develop hardware or because that's less work than maintaining their own patchset).
sdesol 9y ago
It is important to understand development for Linux is heavily driven by a business need. There are more than enough companies (intel, google, etc) that would gladly contribute to Linux, since it makes business sense.
gnaritas 9y ago
Kernel development shouldn't have a low bar, it should have a very very high one. Anyone that finds email a high bar for communication doesn't belong in Kernel development.
- dlp211 9y ago
  This is gate keeping at its finest. Email is a clunky tool to do development with compared with what is available. A persons willingness to use email (and all the quirks for submitting a patch) for patching the kernel has nothing to do with the quality of code that they write.
  - nickbauman 9y ago
    So clunky! :D — With 2000 commits per day, I don't think they need more people. I can't even imagine trying to fit that amount of source code change into any management style, let alone one that has little or no gatekeeping. Making the barrier to entry higher is probably only one step to prevent the project from self-immolation.
    - sverhagen 9y ago
      So they're gating developers by their appreciation of the chosen toolset? Wouldn't you rather see them challenged on their programming abilities? Do you suggest a correlation, I find it hard to believe there is one?
      - coldtea 9y ago
        >So they're gating developers by their appreciation of the chosen toolset? Wouldn't you rather see them challenged on their programming abilities? No, the former is enough. It shows that whatever their programming abilities they are prone to bike-shedding, so they are better avoided.
        jo909 9y ago
        Well they are doing both of course, your patch will still get rejected if it's bad, even if you were able to figure out where and how to send it. But it reduces the amount of patches that need to be read and rejected. Also we are arguing backwards here. They don't make it intentionally hard to keep out new contributors, it's just not important in any way to make it simpler. The goal is to make it work best for the thousands of existing contributors, especially the gatekeeping subsystem maintainers.

chubot 9y ago

Linux is one of the few open source projects to with plenty of developers. They don't need or even want your help, especially if your attitude toward tools is rigid, and if you have nothing concrete to contribute. Linus has said this a few times -- in general they don't actively try to onboard new contributors.

pmoriarty 9y ago
"They don't need or even want your help" There was in fact a talk given by Greg Kroah-Hartman, one Linux's lead maintainers, about development for the Linux kernel which he titled "I Don't Want Your Code". https://www.youtube.com/watch?v=fMeH7wqOwXA https://www.youtube.com/watch?v=fMeH7wqOwXA
- chubot 9y ago
  Haha, thanks for the video. I watched it, and I was surprised to see that it's about a specific company. He's at Linaro, specfically taking their developers to task for sending bad patches. And they indeed sound horrible, but he's good natured about it. I'm just starting to accept patches for my project, and honestly I'm flabberghasted that people will send patches that not only don't run, but don't build. And Greg was saying the same thing. I guess I got spoiled at my last job, where people generally sent high quality patches / code reviews. Although toward the end, I noticed some sloppiness. It wasn't the main reason I left the company, but it started to feel like the downfall... I don't want to work with people who don't know how to submit code reviews / patches.
  - tytso 9y ago
    Linaro isn't a company; it's a "collaborative engineering organization". It does employ some number of engineers, funded by donations by their member companies, but they also accept "in-kind" donations where engineers are detailed to work at Linaro for some period of time. So it wasn't really directed at Linaro per se, but more at the member companies of Linaro.
  - chungy 9y ago
    > I'm just starting to accept patches for my project, and honestly I'm flabberghasted that people will send patches that not only don't run, but don't build. And Greg was saying the same thing. Indeed, I've seen the same thing. I have considered automatically rejecting any patch made with the GitHub online editor (obvious because the committer name is always GitHub). They are pretty much invariably of shit quality.
    - simonh 9y ago
      That's fair enough. The only times I've submitted patches that way is to update documentation files. I'd never submit code that way.
Someone 9y ago
So, what's the age distribution of contributors to the main tree, and how does it develop over time? This _might_ show a long-term risk for Linux.
- wongarsu 9y ago
  80% of the kernel development is done by companies who want their code in the kernel (whether that's because they develop hardware or because that's less work than maintaining their own patchset).

sdesol 9y ago

It is important to understand development for Linux is heavily driven by a business need. There are more than enough companies (intel, google, etc) that would gladly contribute to Linux, since it makes business sense.

gnaritas 9y ago

Kernel development shouldn't have a low bar, it should have a very very high one. Anyone that finds email a high bar for communication doesn't belong in Kernel development.

dlp211 9y ago
This is gate keeping at its finest. Email is a clunky tool to do development with compared with what is available. A persons willingness to use email (and all the quirks for submitting a patch) for patching the kernel has nothing to do with the quality of code that they write.
- nickbauman 9y ago
  So clunky! :D — With 2000 commits per day, I don't think they need more people. I can't even imagine trying to fit that amount of source code change into any management style, let alone one that has little or no gatekeeping. Making the barrier to entry higher is probably only one step to prevent the project from self-immolation.
  - sverhagen 9y ago
    So they're gating developers by their appreciation of the chosen toolset? Wouldn't you rather see them challenged on their programming abilities? Do you suggest a correlation, I find it hard to believe there is one?
    - coldtea 9y ago
      >So they're gating developers by their appreciation of the chosen toolset? Wouldn't you rather see them challenged on their programming abilities? No, the former is enough. It shows that whatever their programming abilities they are prone to bike-shedding, so they are better avoided.
      - jo909 9y ago
        Well they are doing both of course, your patch will still get rejected if it's bad, even if you were able to figure out where and how to send it. But it reduces the amount of patches that need to be read and rejected. Also we are arguing backwards here. They don't make it intentionally hard to keep out new contributors, it's just not important in any way to make it simpler. The goal is to make it work best for the thousands of existing contributors, especially the gatekeeping subsystem maintainers.