On Fri, Sep 18, 2015 at 12:42:48AM -0700, Greg KH wrote: > So don't take cleanup patches for your code, that's fine, and I totally > understand why _you_ don't want to do that. But to blow off the effort > as being somehow trivial and not worthy of us, that's totally missing > the point, and making things harder on yourself in the end. It's not that I think cleanup patches are "trivial and not worthy of us", although I'll note that cleanup patches can end up causing real bug fixes (including possibly fixes that address security problems) to not apply to stable kernels, which means someone needs to deal with failed patches --- or what is much more likely, the failed patch gets bounced back to the overworked maintainer who then drops the patch because he or she doesn't have the bandwidth to manually backport the patch to N different stable trees, and then we all suffer. So cleanup patches *do* have a cost. Rather, what concerns me is that we aren't pushing people to go *beyond* cleanup patches. We have lots of tutorials about how to create perfectly formed patches; but we don't seem to have patches about how to do proper benchmarking. Or how to check system call and ioctl interfaces to make sure the code is doing appropriate input checking. So I don't want to pre-reject these people; but to rather push them and to help them to try their hand at more substantive work. What surprises me is the apparent assumption that people need a huge amount of hand-holding on how to properly form a patch, but that people will be able to figure out how to do proper benchmarking, or design proper abstractions, etc., as skills that will magically appear full-formed into the new kernel programmer's mind without any help or work on our part. > So don't be a jerk, and spout off as to how we only need "skilled" > people contributing. Of course we need that, but the way we get those > people is to help them become skilled, not requiring them to show up > with those skills automatically. I think where we disagree is in how to make them become skilled. I don't think just focusing on contents of SubmittingPatches is sufficient, and there seems to be a "Step 2: And then a miracle occurs" between the SubmittingPatches step and the "skilled contributor" end goal. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html