A quick guide to why stand-alone checkpatch patches suck...

[Valdis.Kletnieks at vt.edu]

On Wed, 17 Sep 2014 08:09:36 -0400, nick said:

> On 14-09-17 08:05 AM, Greg Freemyer wrote:

> > I don't know that chunk of code, but error messages that go to the kernel
> > log exist for a specific reason.  Taking them out requires a specific reason.
> >
> > Ie. This would make a good commit message "At this point the condition is
> > well understood and the code that handles it is well tested and has been stable
> > for 3 years, thus removing the error message."

> This is what I meant with my patch, why have a unneeded error message if the
> code is already tested and only uses
> the return value in that function.

Sorry Nick, but that's *not* what Greg meant.

What he *meant* was that removal of an error message should be its
*own* commit, explaining *why* it was being removed and why it was OK
to do so.

He did *not* say that this particular removal was in fact correct.

He *did* say that such a hypothetical removal *should not* be in a patch
calling itself a checkpatch cleanup.

He *did* say that the patch will require proof that you've examined the
code, understood it, and can explain *why* the patch is OK.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140917/48e5a0b6/attachment.bin