|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 it on linux-kernel and everybody saw it...''||''Christoph said my code is buggy, by office smells and my hair looks strange! He said it on linux-kernel and everybody saw it...''|
|Line 20:||Line 20:|
''"Ask a question, and be a fool for 5 minutes. Remain silent and stay a fool forever."''
Oh no! I got flamed :(
Christoph said my code is buggy, by 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.
"Ask a question, and be a fool for 5 minutes. Remain silent and stay a fool forever."
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!
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