It&#x27;s pretty much all done by emailed patches with git am - I maintain a personal tree on GitHub and one privately in my company, but they&#x27;re purely for experimentation, not for sending pull requests. Email is how we submit code, discuss code and review code. You use git send-email to fire your patches off to the appropriate maintainer + mailing list, you make your modifications&#x2F;rebase it&#x2F;etc then send off V2, V3, ... V14 of your patch until everyone&#x27;s happy. Among other things, we tend to be quite picky about getting commit messages right, and making sure that patch series are &quot;structured&quot; in a &quot;nice&quot; way - so git rebase -i is one of the most common commands I run on my private branches...<p>Maintainers all have their own tools and scripts to help automate and track the whole process - in the area where I work, we track things using Patchwork (see <a href="http:&#x2F;&#x2F;patchwork.ozlabs.org&#x2F;project&#x2F;linuxppc-dev&#x2F;list&#x2F;" rel="nofollow">http:&#x2F;&#x2F;patchwork.ozlabs.org&#x2F;project&#x2F;linuxppc-dev&#x2F;list&#x2F;</a>). When the maintainer&#x27;s happy with a patch, it gets applied and pushed to one of the trees they use (e.g. with powerpc, we have powerpc-next for feature development and powerpc-fixes for important fixes). Eventually, they send Linus a pull request, and it makes its way into the kernel mainline.<p>It&#x27;s a bit of a tricky system that requires understanding of the kernel community&#x27;s social norms to get right - which I&#x27;m not entirely happy with but I don&#x27;t think it&#x27;ll change particularly quickly. However, it&#x27;s also surprisingly effective - the kernel is one of the largest and most distributed individual projects in the open source world, and as a community we keep pushing out releases.