|Deletions are marked like this.||Additions are marked like this.|
|Line 3:||Line 3:|
|''Christoph said my code is buggy, by office smells and my hair looks strange! He said it on linux-kernel and everybody saw it...''||''Christoph said my code is buggy, my office smells and my hair looks strange! He said it on linux-kernel and everybody saw it...''|
Oh no! I got flamed :(
Christoph said my code is buggy, my office smells and my hair looks strange! He said it on linux-kernel and everybody saw it...
Well, let me explain.
You just managed to grab the attention of one of the busiest and best programmers in the world. Now that you have his attention, you should carefully look through the emails you got.
Usually the flames are a small part of the email, and most of the content you receive are useful hints on how to improve your code. You just got free advice from one of the best programmers in Linux!
The best way forward at this point is to follow the advice you got and improve your code in the way suggested.
I don't understand...
If you do not understand all the advice you got, just ask. If you show a willingness to improve your code, developers will usually fall over themselves to help you out. Just make sure to remove the irrelevant parts from your email, so they can focus on those parts of the email that you have questions about.
"He who asks a question is a fool for a minute; he who does not remains a fool forever." -- Chinese proverb
Release early, release often
This strategy is so important that it cannot be repeated often enough.
The larger your project is, the higher the chance that the upstream developers will want something done in a different way. If you wait until the last moment with showing your code to the upstream developers, you will have no time left to change your code in the way required for a successful upstream merge and your project could fail.
On the other hand, if you start engaging the upstream developers while your project is still in the prototype stage, you can get their advice through a much longer time. Not only does this usually result in code that is easier to get merged into the upstream kernel, it can also lead to a good working relationship with the upstream community. Sometimes you even run into other developers wanting to achieve the same goals, and you can get their help with your project!
However, take your time to react to the feedback you received. Releasing the same thing over and over again is often counterproductive. If you post the same broken code 10 times in a row, they will not even review your code the 11th time, even if you finally fixed it then...
Words of wisdom
The Linux kernel community can be your greatest asset if you do things right.
However, if you do approach things the wrong way, they can be your greatest barrier.
In this case, "doing things right" is not just about technical knowledge and skills, but also in your attitude and method of engaging the community.
Some people react badly to smart people. Others take advantage of them. Make sure you are in the second group. -- Linus Torvalds