Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1233889 > unrolled thread

Re: First kernel patch (optimization)

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: First kernel patch (optimization) Thiago Farina <tfransosi@gmail.com> - 2015-09-28 09:00 +0200
    Re: First kernel patch (optimization) Greg KH <gregkh@linuxfoundation.org> - 2015-09-28 16:30 +0200

#1233889 — Re: First kernel patch (optimization)

On Sat, Sep 19, 2015 at 2:18 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Fri, Sep 18, 2015 at 10:26:24PM -0400, Theodore Ts'o wrote:
>> On Fri, Sep 18, 2015 at 12:42:48AM -0700, Greg KH wrote:
>> > So don't take cleanup patches for your code, that's fine, and I totally
>> > understand why _you_ don't want to do that.  But to blow off the effort
>> > as being somehow trivial and not worthy of us, that's totally missing
>> > the point, and making things harder on yourself in the end.
>>
>> It's not that I think cleanup patches are "trivial and not worthy of
>> us", although I'll note that cleanup patches can end up causing real
>> bug fixes (including possibly fixes that address security problems) to
>> not apply to stable kernels, which means someone needs to deal with
>> failed patches --- or what is much more likely, the failed patch gets
>> bounced back to the overworked maintainer who then drops the patch
>> because he or she doesn't have the bandwidth to manually backport the
>> patch to N different stable trees, and then we all suffer.  So cleanup
>> patches *do* have a cost.
>
> All patches have a "cost", and that cost is something that you have to
> deal with as a maintainer.  Nothing new here at all, and if you don't
> like cleanup patches, great, don't take them.  But never go around
> saying that people should NOT send cleanup patches to subsystems you
> don't maintain like you did.  That's rude and unhelpful to everyone
> involved.
>
> The best way to ensure that you never get whitespace patches, is to
> clean your subsystem up.  And frankly, it needs a lot of work, have you
> run checkpatch on it in a while?  You could resolve this issue for
> yourself with a simple afternoon's worth of work.  Why you don't do so
> is a mystery to me.
I think what Theodore was just trying to say is that there are much more
important and pressuring things to do in the kernel (that helps our society)
then doing cleanup patches (what you will tell to your interviewer? That you
fixed the spelling of a word or removed the whitespaces of a source file?).
I think he is just pushing for a more substancial work, that fixes a crash,
improves performance, fixes a subtle bug in some important driver, fixes a
memory leak, etc.

And many maintainers of open source projects that I know off, are not
very welcome
to cleanup patches, especially when the project is mature. They just
call it churn and
turn it down.

-- 
Thiago Farina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1234210

On Mon, Sep 28, 2015 at 03:54:20AM -0300, Thiago Farina wrote:
> And many maintainers of open source projects that I know off, are not
> very welcome to cleanup patches, especially when the project is
> mature. They just call it churn and turn it down.

Then those are not very mature developers as code cruft always needs to
be culled and cleaned on an active project, otherwise it gets harder to
work with over time, as others have already pointed out on this thread.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web