On Tue, Jul 16, 2013 at 08:51:36PM -0400, Steven Rostedt wrote: > On Wed, 2013-07-17 at 08:32 +0800, Jeff Liu wrote: > > > Another thing might deviated from the main theme, but I'd like to raise it > > here because I would like to see what's the proper way for that. > > > > For instance, people A posted a patch set to the mailing list at first, > > people B think that there are some issues in A's implementation, and he > > happened to play around the same stuff recently, so he submitted another > > patch series. Finally, people B made it. > > (In that period, people A kept silent, maybe because he/she was unhappy) > > > > This is a actual occurrence I once observed from a subsystem list(my > > apologies, I just want to talk this case rather than against somebody), > > it seems people A is a new comer(because I can not searched any past > > commits of him/her from the git log), people B is definitely a senior guy. > > > > So that's my question, is that a proper collaboration form in kernel > > community? Does it better if people B could give some suggestions to > > help A to improve the code, especially if those help would help A stepping > > into the kernel development -- maybe it's depend largely on one's opinion. :( > > This is a completely different issue from the one in this thread, but it > is also a legitimate issue and honestly, a bigger one than perceived > insults. > > Is it proper collaboration? Absolutely not. Something that I try to be > sensitive to as it's something I can do as well. There's been things on > my todo list, where someone would send me patches that do it. I would be > thinking "darn it, I wanted to do it" and even worse, the patches that > were sent wouldn't be of the way I wanted them. But I've tried to be > good, and instead of just going about and implementing it myself, I > would try to help the person massage the patches into what I wanted. > That takes a lot of effort and discipline, and honestly, helping someone > else do the work you wanted is much harder than just doing it yourself. > > Sometimes the maintainer just takes the easier route, and does the work > themselves (because it's also more fun too). But that's really a slap in > the face of the person that submitted the work in the first place. If > anything hurts the community, it's this behavior. Not Linus giving > someone an ass wipe. I'm used to practice a workaround for this issue on another project. When a newcomer sends me wrong code trying to address a real issue, I first spend a little time helping him/her. If I see that the gap is too large for him/her to adapt his/her work without too much help from me, then I do the work myself, propose to him/her and once it's OK, and ask him/her to submit the work with his/her name. That way they quickly gain trust in themselves, more easily feel part of the community and get a clearer idea of what is needed. Generally patches quality significantly improves with this, in very short time, because they realize the gap is huge and that they won't get this chance often. My principle is to value the effort more than the result. If the first author spent one week digging into the code to identify an issue and came up with the wrong fix, and I can fix it in 5 minutes, he certainly deserves all the merits for the work, not me. I don't believe this is that much practiced on LKML. I know at least one developer who does this, but he's probably the exception. I more often see counter proposals just as if two authors were fighting to get their patch merged. Willy -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html