On Thu, 22 Sep 2016 13:43:42 +0300, Jani Nikula wrote:
> On Thu, 22 Sep 2016, Jean Delvare <jdelv...@suse.de> 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.
SUSE L3 Support
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html