I wish I could just start reviewing random patches that get submitted/accepted into linux, but it's a daunting task. Although I'm good at C, lacking good knowle

I wish I could just start reviewing random patches that get submitted/accepted into linux, but it's a daunting task. Although I'm good at C, lacking good knowledge of the according subsystem in the kernel makes it impossible to find anything but very trivial errors, which usually get caught by static analyzers afaict. I'm afraid of introducing noise that costs maintainers even more time, by commenting that something might be wrong because "I think you cannot sleep here" or "I think this needs to be in the critical section" when I'm not 100% sure. The sad thing is that the Linux kernel isn't a small simple project, which manifests in many ways. I once debugged and fixed an issue in i915. Finding out where exactly the patch should go, which repo and branch it should be based on, how to format the commit message, etc took at least twice as long as finding and fixing the issue. You end up in some doc listing instructions for a dozen mail clients to configure them so they don't fuck up your patch when you send it. I guess that's why there is "git send-email"; at some point it was easier to add email sending capabilities to freaking git than to deal with email clients, because the whole process is so archaic. I wonder how many people get discouraged by this whole process and just give up. I'd like to think it's just filtering out low effort contributions, but I'm not really sure. Long story short, I think the approachability of the Linux kernel is pretty low and I believe there are a bunch of capable people who'd happily get involved in some way, but are discouraged by the high bar of entry. It's a far stretch from github pull requests and issues usability-wise.