A quite comprehensive set of documents on the submission of patches is available in the Documentation/ part of the kernel source tree and it is important to read. There are two files SubmittingPatches and CodingStyle which cover the important basics but there seems to be very little documentation describing how to go about getting patches merged. Hence, this section will give a brief introduction on how, broadly speaking, patches are managed.
First and foremost, the coding style of the kernel needs to be adhered to as having a style inconsistent with the main kernel will be a barrier to getting merged regardless of the technical merit. Once a patch has been developed, the first problem is to decide where to send it. Kernel development has a definite, if non-apparent, hierarchy of who handles patches and how to get them submitted. As an example, we'll take the case of 2.5.x development.
The first check to make is if the patch is very small or trivial. If it is, post it to the main kernel mailing list. If there is no bad reaction, it can be fed to what is called the Trivial Patch Monkey2.7. The trivial patch monkey is exactly what it sounds like, it takes small patches and feeds them en-masse to the correct people. This is best suited for documentation, commentary or one-liner patches.
Patches are managed through what could be loosely called a set of rings with Linus in the very middle having the final say on what gets accepted into the main tree. Linus, with rare exceptions, accepts patches only from who he refers to as his ``lieutenants'', a group of around 10 people who he trusts to ``feed'' him correct code. An example lieutenant is Andrew Morton, the VM maintainer at time of writing. Any change to the VM has to be accepted by Andrew before it will get to Linus. These people are generally maintainers of a particular system but sometimes will ``feed'' him patches from another subsystem if they feel it is important enough.
Each of the lieutenants are active developers on different subsystems. Just like Linus, they have a small set of developers they trust to be knowledgeable about the patch they are sending but will also pick up patches which affect their subsystem more readily. Depending on the subsystem, the list of people they trust will be heavily influenced by the list of maintainers in the MAINTAINERS file. The second major area of influence will be from the subsystem specific mailing list if there is one. The VM does not have a list of maintainers but it does have a mailing list2.8.
The maintainers and lieutenants are crucial to the acceptance of patches. Linus, broadly speaking, does not appear to wish to be convinced with argument alone on the merit for a significant patch but prefers to hear it from one of his lieutenants, which is understandable considering the volume of patches that exists.
In summary, a new patch should be emailed to the subsystem mailing list cc'd
to the main list to generate discussion. If there is no reaction, it should
be sent to the maintainer for that area of code if there is one and to the
lieutenant if there is not. Once it has been picked up by a maintainer or
lieutenant, chances are it will be merged. The important key is that patches
and ideas must be released early and often so developers have a chance to
look at it while they are still manageable. There are notable cases where
massive patches had difficult getting merged because there were long periods
of silence with little or no discussions. A recent example of this is the
Linux Kernel Crash Dump project which still has not been merged into the
main stream because there has not been favorable responses from lieutenants
or strong support from vendors.