On 09/14/2016 08:33 PM, Greg KH wrote: > On Wed, Sep 14, 2016 at 08:16:55PM +0200, Christian Borntraeger wrote: >> On 09/14/2016 08:06 PM, Joe Perches wrote: >>> On Wed, 2016-09-14 at 19:56 +0200, Christian Borntraeger wrote: >>> >>>> This will certainly help to reduce the noise. On the other hand I remember >>>> Linus >>>> saying something along the line that he does not like the -f parameter >>>> (and he >>>> prefers to set this automatically). So while I like the approach I am not >>>> happy >>>> enough to ack right now - still looking for a better alternative :-/ >>> >>> Linus likely hasn't used checkpatch in a decade or so. >>> >>> Taste and judgment can't be scripted anyway. >>> >>> Let me know if you find an alternative. >> >> You know what. >> with some additional writing like >> "Existing code outside staging is not supposed to be "fixed" to match >> checkpatch. >> Please do not send checkpatch initiated patches for those files" >> near the newly created warn > > That's not true, I _WANT_ checkpatch cleanups for the portion of the > kernel I maintain. It keeps the code correct, up to date, easier to > maintain, and in doing so, we have found real bugs over time.
Assuming that there are others with the same opinions that means that Joes patch is not the right solution? > So don't make a blanket statement like that please. And I'd strongly > suggest you revisit your feelings about this for code you maintain, > unless you want it to bitrot and not get any new contributions or > contributors :) Actually I am totally fine with valid checkpatch patches. (It is embarassing, but I even applied a correct bugfix from Nick Krause). On the other hand I think that there are too many checkpatch or Codingstyle induced patches that actually break code or make things worse. Any better idea is certainly welcome.
