Re: [PATCH] [Coding Style]: misc fixes for fs/ext{3,4}/acl.{c,h} from checkpatch.pl



On Jan 4, 2008 8:41 PM, Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:
[...]
I don't know, because people want to be able to say that they've
contributed fixes to the Linux kernel?

My pet theory is that it is similar to the "unsubscribe me"
cascade effect you sometimes see on mailing lists. One person
sends a "unsubscribe me" to everybody and then suddenly a lot of
people think that is the right way to unsubscribe and reply
with lots of "unsubscribe me too".

So one person sends a cleanup and it gets accepted and suddenly
other people realize it is very easy to do these cleanups
(not realizing the hidden costs they have) and then they go on...

Since I'm one of those people that sent "Codying style fixes" patches
I give my contribution to this discussion as well.

I think that _one_ of the reasons that made a few people sent this kind of
patches to the list is because checkpatch.pl is far better then any other
kerneljanitor scripts/easy task and _seems_ to be an easy way to start
understanding the code, creation of patches and process in general.

I thought we had the janitor project to steer these people into
more useful directions, but apparently that is not well known
enough anymore. Perhaps it just needs to be more regularly announced?

Although I must admit I am not 100% happy with kernel-janitors
either -- e.g. a few times I sent suggestions about easy things
someone could do to that list, but never heard anything back.

Anyways there are lots of ways to do trivial cleanups in a useful
way and if people want to do this perhaps they should just
ask on linux-kernel and people suggest something?

Yes please do that.
Even if fixing errors reported by checkpatch.pl still sounds like a
useful way to spent a couple of hours.
Maybe our mistake was to send the patches to lkml instead of to
trivial@xxxxxxxxxx
or to kerneljanitors?

I mean, I now understand the rationales behind your complaints but I
don't think it's
good idea to discourage people willing to perform easy task.
They just need guidance in order to be useful.

My hope here is of course that these trivial changes are primarily
used as a way to get "the feet wet" to understand the procedures
for contribuing larger not quite as trivial changes

Agreed.

ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • [RFC] HOWTO do Linux kernel development
    ... Linux kernel development, and where to point other people to. ... If anything in this document becomes out of date, please send in patches ... people on the mailing lists are not lawyers, and you should not rely on ...
    (Linux-Kernel)
  • Re: [RFC] MAINTAINERS service, was: Re: alphabetic ordering of MAINTAINERS
    ... kernels, people send patches ... But these are not the people anyway to which this maintainers lookup service would be targeted to. ... the people who want such a service are those who frequently send patches for various different areas of the kernel. ... Some list archives are crap, some lists are subscriber-only, some kernel areas are not covered by a special list. ...
    (Linux-Kernel)
  • Re: [RFC] MAINTAINERS service, was: Re: alphabetic ordering of MAINTAINERS
    ... kernels, people send patches ... areas of the kernel. ... I don't say we replace mailing lists, ... I expect mailing lists to be subscribed to the service. ...
    (Linux-Kernel)
  • Re: Hard freezes with Sid/Experimental
    ... There have been several similar threads on the French and English lists ... despite several tests together with Debian kernel people I couldn't isolate ... It's happening to people with various hardware, ati or amd graphic boards, ... To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx with a subject of "unsubscribe". ...
    (Debian-User)
  • Re: squeeze grep status
    ... lists with regular expressions in this case. ... Argument list too long is utlimately a kernel limitation. ... To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx with a subject ... Trouble? ...
    (Debian-User)