When trying to get source code merged into the upstream kernel, there are a number of things to avoid doing. When you encounter an illustrative example of counterproductive behaviour by somebody trying to get code merged, please document it here.
Contents
The gentle art of making enemies
Like the scientific community, the Linux kernel community operates on a consensus basis. One of the methods of getting your code accepted is by gathering support from other Linux kernel developers. There are a number of obvious ways of turning these people against you, instead of having them work with you.
Your code sucks
While it is sometimes true that some of the code that is in the Linux kernel sucks, pointing this out in a belligerent way is unproductive. You will be much better off proposing improvements to the code, or asking the maintainers what approach for improving the code in question they would like to see.
Idiots! All of you!
Sometimes a grand new concept is dumped on the Linux kernel community. At least, the author of the proposal would like to think so. It is common for denizens on the linux-kernel mailing list to disagree with some of the aspects of that grand proposal. In this situation, you can take a number of approaches.
Some people react badly to smart people. Others take advantage of them. Make sure you are in the second group. -- Linus Torvalds
However, some people react badly to the opinions and suggestions of the people who took hours out of their time to review their code. Some people even flame them to a crisp. Once you have turned enough of the linux-kernel "top dogs" against you, it will become extremely hard to get your code merged. If only because nobody will take the time again to review the next iteration of your code.
For an example of what personality clashes can do, take a look at WhyReiser4IsNotIn.
I don't care about your needs
My code solves my problem. Frankly I don't care that it breaks Linus's workstation, he should just merge my code and fix it!
Obviously Linus will not merge code that introduces bugs for other people's use cases. More subtle is the case where multiple groups of developers are trying to merge code that does something similar, but does not solve each other's issues.
One example of this is the in-kernel virtualization and/or resource management functionality implemented by CKRM, OpenVZ and linux-vserver. All of these projects introduce much-wanted functionality, but none of them quite do what the others do. Furthermore, merging one means the others cannot be merged.
This is a good example because the developers of these projects are actually playing nice and working together towards a common solution, which solves everybody's problems as elegantly as possible. One of the lessons that can be learned from this is that it does not really matter if it is your code that goes upstream, as long as the code that does go upstream happens to fit your requirements. An additional benefit is that there are now more people requiring the (new) code, which helps a lot when trying to convince Linus and Andrew that the added complexity is worth it.
But we've always worked this way
Our company has worked this way for decades. We are not going to change our code for Linux.
In order to keep Linux portable between different architectures and easily maintainable in the future, a number of processes and coding guidelines have been developed. There are reasons why things are done the way they are, and if you want your code to be merged upstream you should try to be flexible.
When Linus merges your code, the Linux kernel community is taking on part of the burden of maintaining your code. Please be considerate.
Back to UpstreamMerge.