Re: [PATCH 2/3] orangefs: Dan Carpenter influenced cleanups...

[Martin Brandenburg <martin@omnibond.com>]

On Wed, 12 Apr 2017, Greg KH wrote:

> On Tue, Apr 11, 2017 at 12:41:27PM -0400, Martin Brandenburg wrote:
> > From: Mike Marshall <hubcap@omnibond.com>
> > 
> > commit 05973c2efb40122f2a9ecde2d065f7ea5068d024 upstream.
> > 
> > This patch is simlar to one Dan Carpenter sent me, cleans
> > up some return codes and whitespace errors. There was one
> > place where he thought inserting an error message into
> > the ring buffer might be too chatty, I hope I convinced him
> > othewise. As a consolation <g> I changed a truly chatty
> > error message in another location into a debug message,
> > system-admins had already yelled at me about that one...
> > 
> > Signed-off-by: Mike Marshall <hubcap@omnibond.com>
> > 
> > I have removed the return code and whitespace fixes as they do not cause
> > a real bug.  I keep the removal of an error message.  This error shows
> > up when a process dies before the OrangeFS userspace client responds.
> > This happens all the time on production systems and fills up the ring
> > buffer.
> 
> No, please keep patches identical to what is in Linus's tree.  That way
> you don't mess something up, and any future patches over the next 2+
> years the kernel tree will be around apply cleanly.
> 
> Almost every single time we "modify" a patch from what is in Linus's
> tree it is broken.
> 
> I've taken the original patch here for 4.9 and 4.10 stable trees.

I based that on this line in stable-kernel-rules.rst

 - It cannot contain any "trivial" fixes in it (spelling changes,
   whitespace cleanups, etc).

but I do see your point.  Does that just mean pure trivial patches are
inappropriate, but that if one or two trivial changes comes part and
parcel with a more significant patch it should be kept?

(Honestly what I removed are slightly more than trivial whitespace,
though I wouldn't have sent them on their own if they didn't come with
the logging change.)

Martin

> 
> thanks,
> 
> greg k-h
>