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.

Some things need to be gatekept. (One obvious example is OS kernels.)

If you won't submit a kernel patch because you feel that email is unfashionable, then you're kind that should be kept out of the gate. Sorry.

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?

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

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.

>This is gate keeping at its finest.

That's as intended.