3 ms·

>> But if you can tell the code is wrong, then give reasons for why it is wrong, tell them you can not commit until those reasons are corrected, and do so in a

>> But if you can tell the code is wrong, then give reasons for why it is wrong, tell them you can not commit until those reasons are corrected, and do so in a polite manner. In addition, by providing resources, you make your own job easier as the quality of patches continues to improve in quality, you retain talent, and foster new talent within the software community. One of the problems with assumptions here is that kernel maintainers by definition shall know that their code is wrong and why it is wrong . If this is not true, they shall not be kernel maintainers. Another one is that Linus does not need to retain talent that can not perform to acceptable standards. Please note that acceptable standards are different for different people.

codyb 13y ago
No this is totally true and I agree. But if you can mold someone into performing at acceptable standards than you have more talent which produces better products faster. That's basically my reasoning for my approach. If you do not know why the code is wrong, then tell them what it is doing wrong in a similar fashion. "Hey John, I see you updated this patch. Thanks but it seems to be hogging memory. What can you do about that?" Perhaps you point them to people who have worked in that area before. "Well you working on I/O, you know Tim over here has worked in that area before, he might be busy but if you can't figure it out on your own maybe you can shoot him a question and see if replies." I guess a kernel maintainer may never make a mistake since you assume it is a tautology that all kernel maintainers by definition know when and where and why their code is wrong or they could not be kernel maintainers. Or you're implying that any kernel retainer will, upon being notified, no matter the language of the rebuke, immediately know how to fix it and will also be willing to do so. There are also different levels of experience for different people. It doesn't mean you should throw them off the ship or so harshly rebuke them that they never return to the project. And if there are different standards than you probably don't need to give everyone the harshest standard. Alright but I've posted enough in this thread.

codyb 13y ago

No this is totally true and I agree. But if you can mold someone into performing at acceptable standards than you have more talent which produces better products faster. That's basically my reasoning for my approach. If you do not know why the code is wrong, then tell them what it is doing wrong in a similar fashion. "Hey John, I see you updated this patch. Thanks but it seems to be hogging memory. What can you do about that?" Perhaps you point them to people who have worked in that area before. "Well you working on I/O, you know Tim over here has worked in that area before, he might be busy but if you can't figure it out on your own maybe you can shoot him a question and see if replies." I guess a kernel maintainer may never make a mistake since you assume it is a tautology that all kernel maintainers by definition know when and where and why their code is wrong or they could not be kernel maintainers. Or you're implying that any kernel retainer will, upon being notified, no matter the language of the rebuke, immediately know how to fix it and will also be willing to do so. There are also different levels of experience for different people. It doesn't mean you should throw them off the ship or so harshly rebuke them that they never return to the project. And if there are different standards than you probably don't need to give everyone the harshest standard. Alright but I've posted enough in this thread.