6.3: Other things that can happen

One day, you may open your mail client and see that somebody has mailed you a patch to your code. That is one of the advantages of having your code out there in the open, after all. If you agree with the patch, you can either forward it on to the subsystem maintainer (be sure to include a proper From: line so that the attribution is correct, and add a signoff of your own), or send an Acked-by: response back and let the original poster send it upward.

If you disagree with the patch, send a polite response explaining why. If possible, tell the author what changes need to be made to make the patch acceptable to you. There is a certain resistance to merging patches which are opposed by the author and maintainer of the code, but it only goes so far. If you are seen as needlessly blocking good work, those patches will eventually flow around you and get into the mainline anyway. In the Linux kernel, nobody has absolute veto power over any code. Except maybe Linus.

On very rare occasion, you may see something completely different: another developer posts a different solution to your problem. At that point, chances are that one of the two patches will not be merged, and "mine was here first" is not considered to be a compelling technical argument. If somebody else's patch displaces yours and gets into the mainline, there is really only one way to respond: be pleased that your problem got solved and get on with your work. Having one's work shoved aside in this manner can be hurtful and discouraging, but the community will remember your reaction long after they have forgotten whose patch actually got merged.