> 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.
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.
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".
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.
> 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.
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.
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).
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.
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.
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.
You can send a patch to a mailing list with `git send-email`. You can format it first with `git format-patch` and then send the patch with `git send-email`. Configuring it to use your email server takes a few minutes, and you only have to do it once.
I get the feeling most people who complain about how "clunky" email is have never actually tried to submit a patch to LKML. If I could figure it out when I was a high-school student, a professional developer should be able to figure it out as well.
> Email is a clunky tool to do development with compared with what is available.
The linked article explains at length why it works well for kernel maintainers. And since it does, why should kernel maintainers change it just to make things easier on newbies? It's much more reasonable to expect new participants to adapt to a workflow that works, than vice versa.
This is not "gatekeeping," it's just the reality that not everyone works the same way.
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.
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?
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.
>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.
Generally yes, but IIRC Linus has explicitly said that he likes the process being intentionally hard to keep out new contributors.
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.