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. > > 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 :) > > thanks, > > greg k-h >
After some days of time going by I have to agree with you. It has never been a checkpatch patch that bothered me, instead only some (and rare) fruitless discussions and ignorance of feedback of very few people made me "unhappy". Certainly nothing where a "stiff-armed" checkpatch would help. The other question might be still an interesting topic: The process of how to update CodingStyle and how detailed Codingstyle. Christian
