Hi Jani, On Thu, 22 Sep 2016 13:43:42 +0300, Jani Nikula wrote: > On Thu, 22 Sep 2016, Jean Delvare <jdelvare@xxxxxxx> wrote: > > You need to think in terms of actual use cases. Who uses checkpatch and > > why? I think there are 3 groups of users: > > * Beginners. They won't run the script by themselves, instead they will > > submit a patch which infringes a lot of coding style rules, and the > > maintainer will point them to checkpatch and ask for a resubmission > > which makes checkpatch happy. Being beginners, they can only rely on > > the script itself to only report things which need to be fixed, by > > default. > > * Experienced developers. Who simply want to make sure they did not > > overlook anything before they post their work for review. They have > > the knowledge to decide if they want to ignore some of the warnings. > > * People with too much spare time, looking for anything they could > > "contribute" to the kernel. They will use --subjective and piss off > > every maintainer they can find. > > > > Sadly there's not much we can do about the third category, short of > > killing option --subjective altogether. > > You could make checkpatch have different defaults for patches and files, > to encourage better style in new code, but to discourage finding > problems in existing code. Fixing old code isn't wrong per se. It's good actually. But only if done the right way by the right person. I don't think it makes any sense to use this task as an introduction to kernel development for newcomers. It doesn't teach them anything about the kernel, really. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
