Standard indentation of arguments.

I use right blank space to displace the last table, in order to make the arguments alining. For example:
old:

extern void test_fun(struct list_head *new,

			struct list_head *prev,

			struct list_head *next);

new:

extern void test_fun(struct list_head *new,

		     struct list_head *prev,

		     struct list_head *next);
Signed-off-by: Jianjun Kong <kongjianjun@gmail.com>

---

 include/linux/list.h |   27 ++++++++++++++-------------

 1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/include/linux/list.h b/include/linux/list.h

index 08cf4f6..6d16696 100644

--- a/include/linux/list.h

+++ b/include/linux/list.h

@@ -49,8 +49,8 @@ static inline void __list_add(struct list_head *new,

 }

 #else

 extern void __list_add(struct list_head *new,

-			      struct list_head *prev,

-			      struct list_head *next);

+		       struct list_head *prev,

+		       struct list_head *next);

 #endif
 /**

@@ -91,7 +91,8 @@ static inline void list_add_tail(struct list_head *new, struct list_head *head)

  * the prev/next entries already!

  */

 static inline void __list_add_rcu(struct list_head * new,

-		struct list_head * prev, struct list_head * next)

+				  struct list_head * prev,

+				  struct list_head * next)

 {

 	new->next = next;

 	new->prev = prev;

@@ -138,7 +139,7 @@ static inline void list_add_rcu(struct list_head *new, struct list_head *head)

  * list_for_each_entry_rcu().

  */

 static inline void list_add_tail_rcu(struct list_head *new,

-					struct list_head *head)

+				     struct list_head *head)

 {

 	__list_add_rcu(new, head->prev, head);

 }

@@ -220,7 +221,7 @@ static inline void list_replace(struct list_head *old,

 }
 static inline void list_replace_init(struct list_head *old,

-					struct list_head *new)

+				     struct list_head *new)

 {

 	list_replace(old, new);

 	INIT_LIST_HEAD(old);

@@ -235,7 +236,7 @@ static inline void list_replace_init(struct list_head *old,

  * Note: @old should not b...
[ message continues ]

This is a call for discussion for new maillist on vger.
List name: linux-wanking@vger.kernel.org
Rationale: the need for such list has been demonstrated during the last few

months by rapid increase in the amount of traffic topical for such list

(and completely unrelated to any kind of kernel development) misposted on

linux-kernel.  A separate list dedicated to this kind of self-gratification

would hopefully

	* reduce the gag reflex among the l-k readers

	* provide a forum where such activity could be indulged in comfort

and safety from mocking

	* in cases inspiring Ingo's theory of spontaneous onset of sanity,

shield the emerging sentients from the prejudice created by their previous

output.
Exhibit A:
Further examples can be trivially found in l-k archives and will be provided

on demand.

--

Oh, what a marvellous way to encourage new contributors that was. Thank

you so much.
For the record: Al speaks only for himself and a lack of expressed

disagrement from others should not be taken as agreement.
Sheesh.

--

But I'd like to second the opinion.  This is getting a little too far.

We should rather try to at least enforce very basic standards a lot of

the crap shoved in doesn't follow instead of wanking around about exact

placement of whitespaces.
--

The real question is whether people who are wanking about whitespace

and spelling fixes in comments will graduate to writing real, useful

patches.  If they won't, there's no point to encouraging them.
						- Ted

--

Guys, get a clue.  It doesn't matter what that person did.  It is the

effect upon *all* other potential developers which is so damaging here.

Not upon this individual.

--

From: Andrew Morton <akpm@linux-foundation.org>
You can't have your cake and eat it too Andrew.
It's only a half-story to talk about future contributors when current

trends on this list are making things bad for existing folks doing

useful work.
You make it sound like it's this one sided story where we have to be

all nicey nicey to everybody so that new contributors aren't discouraged,

and that's where it ends.
But we're currently encouraging a society of bottom feeders.  And

bottom feeders, although erroneously perceived as being good for the

fish tank, actually end up making the tank more dirty in the end.

So this is a trend we have to reverse now.
And we're not going to close cultural gaps by making Al Viro or any

other major kernel contributor quiet about things like this.  Don't be

so naive Andrew.  The problem is so much larger than that.

--

Sigh...  <mode=Andrew> Let me make it clear that Davem is not speaking for

me </mode>.
It's NOT about personalities of people submitting patches.  I don't know

them and I absolutely do not believe that either personality per se or

expected future behaviour can be derived from the fact of having sent this

kind of junk.
So "bottom-feeders" is IMO uncalled for - it presumes far more personal

and permanent features that simply are not in evidence.
Moreover, I'm less concerned about demoralizing effects of any description on

the existing developers.  Sure, that stuff is annoying, but it takes more than

that to really screw us.
I *am* concerned about new contributors.  Especially ones doing janitor-style

work, and yes, it's a great way to get started and it's very much needed.

What I've been seeing during the last months is continued devaluation of

such work in general.  By mixing really worthwhile things with more and more

pointless ones in the same bag and by trends that make the low-end side of

that more visible at the expense of those newbies who actually do something.

I'll abstain from naming names, since I rather doubt that anyone would

appreciate being brought into this flamefest in any capacity, let alone as

an exhibit of what one _should_ do in opinion of some participants, but

we still get new people who move on to doing sane work.
Look at that as a dynamic system.  Most of us do different kinds of work -

a mix of various tree- or subsystem-wide janitorial stuff, diving into

isolated drivers, API cleanups, bug hunting of various kinds, regression

tracking, development of new code, be it individual drivers or new features

in subsystems, etc.  The mix varies from person to person and from week

to week.  Right?  Maintaining subsystems is just one more thing in the

mix - it's not something inherently special or permanent, BTW.
We all keep moving on to some extent; what matters is the dynamics of that.

At some point things get interesting enough to encourage o...
[ message continues ]

[Andrew Morton - Wed, May 21, 2008 at 10:46:44AM -0700]

| On Wed, 21 May 2008 08:09:39 -0400 Theodore Tso <tytso@mit.edu> wrote:

|

| > On Wed, May 21, 2008 at 06:32:06AM -0400, Christoph Hellwig wrote:

| > > On Wed, May 21, 2008 at 01:50:37AM -0700, Andrew Morton wrote:

| > > > Oh, what a marvellous way to encourage new contributors that was. Thank

| > > > you so much.

| > > >

| > > > For the record: Al speaks only for himself and a lack of expressed

| > > > disagrement from others should not be taken as agreement.

| > >

| > > But I'd like to second the opinion.  This is getting a little too far.

| > > We should rather try to at least enforce very basic standards a lot of

| > > the crap shoved in doesn't follow instead of wanking around about exact

| > > placement of whitespaces.

| >

| > The real question is whether people who are wanking about whitespace

| > and spelling fixes in comments will graduate to writing real, useful

| > patches.  If they won't, there's no point to encouraging them.

| >

|

| Guys, get a clue.  It doesn't matter what that person did.  It is the

| effect upon *all* other potential developers which is so damaging here.

| Not upon this individual.

| 
Btw, we have CodingStyle, SubmittingPatches and other, but why don't

we have something like KernelNewbieGuide? Don't get me wrong, but

there could be written all rules about - what is good to do, what is bad.

So a newbiew who wants to be usefull for kernel could read it and decide

what should be done. /Don't beat me ;) / And of course I know about

kernelnewbie.org but this (even quite short) document could help I think.
		- Cyrill -

--

Hi,
How about the following?
---
From: Johannes Weiner <hannes@saeurebad.de>

Subject: [PATCH] CodingStyle: no more trivial coding style fixes, please
Add a note to CodingStyle that style cleanups should only be done if the

code is really offending and violating the kernel conventions heavily.

But no more oneliners fixing indentation and the like.
Signed-off-by: Johannes Weiner <hannes@saeurebad.de>

---
 Documentation/CodingStyle |   12 ++++++++++++

 1 file changed, 12 insertions(+)
--- a/Documentation/CodingStyle

+++ b/Documentation/CodingStyle

@@ -783,6 +783,18 @@ own custom mode, or may have some other

 work correctly.
+		Chapter 19:  No coding style patches, please

+

+While all these conventions should be honored when writing new code

+please do not send patches that fix minimal coding style issues only.

+

+If a whole file or several logically connected ones are in a really

+bad shape (i.e. violating several points named here), a patch cleaning

+them up in one go is okay.

+

+But do not send patches that fix indentation of two lines.  It is not

+worth the effort.

+
 		Appendix I: References
--

[Johannes Weiner - Wed, May 21, 2008 at 09:42:32PM +0200]

| Hi,

|

| Cyrill Gorcunov <gorcunov@gmail.com> writes:

|

| > [Andrew Morton - Wed, May 21, 2008 at 10:46:44AM -0700]

| > | On Wed, 21 May 2008 08:09:39 -0400 Theodore Tso <tytso@mit.edu> wrote:

| > |

| > | > On Wed, May 21, 2008 at 06:32:06AM -0400, Christoph Hellwig wrote:

| > | > > On Wed, May 21, 2008 at 01:50:37AM -0700, Andrew Morton wrote:

| > | > > > Oh, what a marvellous way to encourage new contributors that was. Thank

| > | > > > you so much.

| > | > > >

| > | > > > For the record: Al speaks only for himself and a lack of expressed

| > | > > > disagrement from others should not be taken as agreement.

| > | > >

| > | > > But I'd like to second the opinion.  This is getting a little too far.

| > | > > We should rather try to at least enforce very basic standards a lot of

| > | > > the crap shoved in doesn't follow instead of wanking around about exact

| > | > > placement of whitespaces.

| > | >

| > | > The real question is whether people who are wanking about whitespace

| > | > and spelling fixes in comments will graduate to writing real, useful

| > | > patches.  If they won't, there's no point to encouraging them.

| > | >

| > |

| > | Guys, get a clue.  It doesn't matter what that person did.  It is the

| > | effect upon *all* other potential developers which is so damaging here.

| > | Not upon this individual.

| > |

| >

| > Btw, we have CodingStyle, SubmittingPatches and other, but why don't

| > we have something like KernelNewbieGuide? Don't get me wrong, but

| > there could be written all rules about - what is good to do, what is bad.

| > So a newbiew who wants to be usefull for kernel could read it and decide

| > what should be done. /Don't beat me ;) / And of course I know about

| > kernelnewbie....
[ message continues ]

I did a talk on Linux "social engineering" at {OSCON, IEEE NW something,

and SCALE}.  All about what (not) to do, how to do it, etc.

Slides for it are available in http://www.xenotime.net/linux/mentor/ .
---

~Randy

--

[Randy Dunlap - Wed, May 21, 2008 at 12:33:55PM -0700]

| On Wed, 21 May 2008 22:57:25 +0400 Cyrill Gorcunov wrote:

|

| > [Andrew Morton - Wed, May 21, 2008 at 10:46:44AM -0700]

| > | On Wed, 21 May 2008 08:09:39 -0400 Theodore Tso <tytso@mit.edu> wrote:

| > |

| > | > On Wed, May 21, 2008 at 06:32:06AM -0400, Christoph Hellwig wrote:

| > | > > On Wed, May 21, 2008 at 01:50:37AM -0700, Andrew Morton wrote:

| > | > > > Oh, what a marvellous way to encourage new contributors that was. Thank

| > | > > > you so much.

| > | > > >

| > | > > > For the record: Al speaks only for himself and a lack of expressed

| > | > > > disagrement from others should not be taken as agreement.

| > | > >

| > | > > But I'd like to second the opinion.  This is getting a little too far.

| > | > > We should rather try to at least enforce very basic standards a lot of

| > | > > the crap shoved in doesn't follow instead of wanking around about exact

| > | > > placement of whitespaces.

| > | >

| > | > The real question is whether people who are wanking about whitespace

| > | > and spelling fixes in comments will graduate to writing real, useful

| > | > patches.  If they won't, there's no point to encouraging them.

| > | >

| > |

| > | Guys, get a clue.  It doesn't matter what that person did.  It is the

| > | effect upon *all* other potential developers which is so damaging here.

| > | Not upon this individual.

| > |

| >

| > Btw, we have CodingStyle, SubmittingPatches and other, but why don't

| > we have something like KernelNewbieGuide? Don't get me wrong, but

| > there could be written all rules about - what is good to do, what is bad.

| > So a newbiew who wants to be usefull for kernel could read it and decide

| > what should be done. /Don't beat me ;) / And of course I know about

| > kernelnewbie.org bu...
[ message continues ]

On Wed, 21 May 2008 23:45:22 +0400
Yes, a general GettingStarted document would probably be useful.

It would hopefully have more what-to-do content than what-not-to-do.

--

I'm in the process of trying to write an initial draft of just such a

document right now. I'll post it once I'm a bit more done (gimme an

hour or two).
--

Jesper Juhl <jesper.juhl@gmail.com>

Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html

Plain text mails only, please http://www.expita.com/nomime.html

--

In theory, that's Documentation/HOWTO.  In practice, quite a bit more is

needed.  I'm actually in the process of writing such a thing as well,

with some support from the Linux Foundation.  I'll not have it done in

an hour or two, though; a version for review in June is more likely... 
jon

--

What I'm doing right now is basically reformatting my own notes,

emails I've written on the subject, pieces of other documents I've

written etc etc and trying to put them in the shape of a Getting

Started document.  Perhaps getting that compiled into a reasonable

document in a few hours is a bit too optimistic, but I'll give it a

go, post what I have for review and we can take it from there.  :-)
I'd love to read your document once it's ready for review.
--

Jesper Juhl <jesper.juhl@gmail.com>

Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html

Plain text mails only, please http://www.expita.com/nomime.html

--

Suggestions ...
"addressed".
I'd probably make a few grammatical changes too. When you're happy

with the content and your document is in the tree, I'll submit a

patch :-)
Nick.

--

PGP Key ID = 0x418487E7                      http://www.nick-andrew.net/

PGP Key fingerprint = B3ED 6894 8E49 1770 C24A  67E3 6266 6EB9 4184 87E7

--

On Thu, 22 May 2008, Jesper Juhl wrote:
here you mean NACK not ACK
David Lang

--

On Thu, May 22, 2008 at 3:46 AM, Jesper Juhl <jesper.juhl@gmail.com> wrote:

[...]
Quite good document, I must say. Jesper, I think that part of

text (what to stay away from) *must* be marked special somehow.

I'm not sure if every newbie would read this document before sending

patch but we will be able to say "Hey, we warned you not the once

about useless work! Don't do that again!" (maybe it should be

even CAPITALIZED)

--

Hi,
  - Run a recent development kernel.  If you already know an area that

    might interest you, use the tree of that subsystem.  Otherwise
  - Read the mailing list.  Again, if you are interested in a specific

    area, there are also subsystem-related mailing lists, check

    http://vger.kernel.org/vger-lists.html.
Probably needs some rephrasing...
	Hannes

--

But fixing them is not so easy...
Sorry for being destructive, but we do not have easy coding tasks

for newbies.
If it's easy it's already fixed, and dozens of people following your

advice to look at e.g. compile or sparse warnings will only generate

much noise, but they'll have a hard time finding anything they are

capable to fix.
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

On Thu, 22 May 2008 03:12:33 +0300
Sorry but if it's too easy, you don't learn from it. If it's not a
If they only go where they are already capable.. no gain for anyone.

A bug can be a challenge, and need a lot of learning and investigating.

And that's *FINE*. That's what you learn from. Not from the actual fix

itself.
--

Hmm... yes, we do have easy coding tasks, but you need the hardware.
For example w35und wireless driver is in desperate need of few

developers. Many more such projects exist... but you need the

hardware.

								Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

Really. I'd go read some of the less maintained driver code for an

afternoon.
Alan

--

A) You are not being destructive, you are doing exactely what I hoped
B) You are absolutely right in saying that fixing bugs is not (always)

easy. But it's a fact that many people ask questions along the lines

of "where do I start?", "where can I find something useful to work

on?", "I want to learn, is there some code that needs attention I can

start reading?" and similar. I'm simply trying to help the people who

ask that sort of questions by providing them with a source of stuff to

attack. Whether or not someone will be able to fix a bug is a

different issue to whether or not a person can find somewhere to start
True, and then again, not always.  Do 100 randconfig builds and I'm

willing to bet that at least a handful of the compiler errors or

warnings you encounter can be fixed by simply including a header,

moving an #ifdef, fixing a cast, fixing a printk format string or

similar.

There are many difficult to fix bugs in the kernel, but there's also

still some low-hanging fruit left (and I suspect there will always

You may be right, but personally I'm not so sure. The kernel is a

large project and we have many people who want to get involved but

give up when hitting the very first barrier to entry; finding

somewhere to start. Sure, there will be some noise, but I would hope

that there would also be many good (if somewhat trivial) patches - and

once people get one or two trivial patches accepted they may be

encouraged to delve in deeper and do more useful work.

Those that can't even fix a simple warning or missing include file

error will probably give up whether or not we provide this document or

not.
--

Jesper Juhl <jesper.juhl@gmail.com>

Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html

Plain text mails only, please http://www.expita.com/nomime.html

--

On Thu, May 22, 2008 at 01:46:28AM +0200, Jesper Juhl wrote:
If you are familiar with C, reading the kernel source (e.g. starting

at system call and going down from there) can be very useful; you will

need such skills anyway and you might actually find real bugs.
Asking the questions along the lines "code seems to assume that <this> never

happens; why can't it happen and what happens if it does?" is generally

welcome, assuming that question is more or less coherent.  "I do not

understand this code at all" will be less useful and "<this> is <expletives>

BROKEN!!!  I've found a major hole!!!" would better be right - which is not

impossible.  Use common sense; if you turn out to be wrong (which is also

quite possible), the size of crow you'll have to eat will be directly

proportional to the vehemence of the original posting.  That applies to all

of us - pretty much everyone had been there and probably will be there again

and again.  On the other hand, do not be surprised if the answer will be

"It's because...  Umm...  Oh, !@#!@#, looks like you've spotted a nasty hole".

It also happens and assuming that code is correct just because it is in the

tree is a bad mistake.  Newbies can and do find serious bugs and doing that
Note that fixing up coding style in the code you are modifying is fine,

provided that coding style part does not obscure the real changes you

are making and the scale of coding style changes is not wildly out of

proportion.  Again, use the common sense - changing two lines in a function

is not a reason to reformat every file in directory while you are at it.

--

Thanks a lot for your comments Al.

I'll try to incorporate most of it in the next revision of the document.
--

Jesper Juhl <jesper.juhl@gmail.com>

Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html

Plain text mails only, please http://www.expita.com/nomime.html

--

On Wed, 21 May 2008 22:57:25 +0400
There are a lot of people out there who would like to try their hands

at kernel.org development but who just aren't sure how to start, nor

where to start.
One could understand a developer deciding to write a do-nothing

whitespace patch as a general throat-clearing exercise, but when asked,

I recommend against that.  I generally recommend that people just

download and test the latest -rc, linux-next and -mm kernels and build

and run them.  Because they surely will find things which need fixing.

Often simple little things like compilation errors, sometimes things

which need a bisection search.
For more substantial starter projects the best we have (as far as I

know) is http://kernelnewbies.org/KernelProjects, but that's just a

teeny subset.
We're not very good at this, I'm afraid.  I seem to recall that Rik has

offered to help out here, so perhaps whenever one notices a

hey-someone-should-do-this project, it could be forwarded to Rik and he

can put it up there.
The #1 project for all kernel beginners should surely be "make sure

that the kernel runs perfectly at all times on all machines which you

can lay your hands on".  Usually the way to do this is to work with

others on getting things fixed up (this can require persistence!) but

that's fine - it's a part of kernel development.
--

Let's look at it from another angle:
We should not aim at being good at this.
What do we need more in the kernel:

- people testing development kernels

- people fixing bugs

- people maintaining code

- people reviewing code
What do we already have more than enough:

- people developing new bugs^Wfeatures
If someone wants to do a project that's OK.

And if some kernel developer wants to assist him that's OK.
But in my opinion stuff like "I need a project for university" requests

are not our problem, and they tend to not bring much for us.
Offering any serious mentoring for newbies will only keep developers

busy who could otherwise do things that would bring more value to the

kernel.
And we've just seen that having people who do not even know the basics

of C sending dozens of checkpatch cleanups doesn't bring us any gain.
There are many other open source projects where it might be easier to

get started and that are really looking for people wanting to get 
Fully agreed, and this is the only area I see where a newbie can be a

net win for us from the first second.
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

- companies being content with out-of-tree drivers or even closed

    source drivers or no drivers at all, and users having to put up

    with it

--

Stefan Richter

-=====-==--- -=-= =-==-

http://arcgraph.de/sr/

--

*blink*
OK, I give up; how was it supposed to be parsed?  I can't come up with any

way of reading that sentence that would not be an obvious glaring idiocy

and I don't see any obvious typos or word omissions that could have created

that.
Surely you are not saying that we are not really looking for more people

doing useful work?  And doing that without "getting involved"... could

any resident Zen master enlighten me?  I seem to be unable to figure out

how the hell one could pull off such a feat...

--

Sorry, I am not a native English speaker.
Perhaps my phrase was too long?

Or did I take a word wrongly from the dictionary?
Is it perhaps better understandable as follows:
There are many other open source projects where it might be easier to

get started. This is since they are really (=desperately) looking for

more people who want to get involved (=want to participate).
Or completely paraphrased:
We cannot offer intensive mentoring for everyone.
But people looking for more mentoring can find this in other open source

projects.
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

> We cannot offer intensive mentoring for everyone.
You don't need too - see kernel-newbies and the kernel janitors projects.

Especially the former. Give people a bit of support and they'll tend to

mentor each other.
Alan

--

There is the question of exactly how long you'd like this project to

survive though (in a vibrant form).
Remarked elsewhere recently that a downside of the new development model

seems to be missing opportunity for new editions of books with "all new!

covers 2.8!" blurps on the cover.
That is, not seeing quality documentation emerge, not seeing mentoring

from experienced developers... -- where and how do you want the new

developers to come from? If only from business linux as a community

thing is as dead as when you'd just close shop.
Rene.

--

We are drowning in new code, and our biggest problem is to get it

properly integrated.
We don't have any shortage in the sheer number of people, and it doesn't

seem we'll ever have.
And we have many newbies who come and find themselves areas for useful 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

I'd worry that it does seem exactly like that. This thread is (again)

about newbies being distracted by the robotic aspects and not moving out

  of that easily or quickly -- about a worry that too few new developers 
Useful contributions don't translate one on one into capable future

developers.
Rene.

--

We must also somehow manage to integrate hardware drivers that are 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

Some of us never manage to escape from that level.  I dug around, and I've been

playing the "What did -mm break on me *this* time?" since 2.5.55-mm1. :)

From: Andrew Morton <akpm@linux-foundation.org>
Indeed.  A lot of the time I see new people, or people making

suggestions to them, so fixated on wanting to implement new features.
To me that is absolutely the wrong way to go about this.
It's so much more useful, for both the community and the individual,

to fix bugs.  Fixing a bug forces you to learn how the kernel works at

least on some level, and fixing a bug always makes Linux better.
Implementing a new feature does not necessarily have either of those

two important qualities, so it is never the place for new people to

start.
Fixing bugs will give someone a real identity and place in the

community.
You want real Linux kernel "street cred"?  Fix a lot of bugs, then you

can implement a thousand new features and people will take you

seriously because you've shown that you can and will fix things.

--

I think that they are often young and want to get their name associated
Not that much for newbies. Linux is thought^Wknown to be bug-free. People

don't get a name by claiming everywhere "hey, I found bug X which I could

trigger by doing stupid thing Y, and I could fix it, I've contributed".
On the opposite, they have the ability to say "hey friends, now you can

buy webcam XX, I have implemented support for it" (often meaning

"I send a PCI ID update"). This is a lot more rewarding for them.

I've encountered a lot of them. There is a general culture of visible

and measurable results, and that's why people focus more on creating

than fixing.
Speaking for myself, I clearly prefer being responsible of getting

something to work very well and have happy users than to have a ton

of users whine about my bugs. But I know this is not common, and I

often see people asking what motivates me in stabilizing things and

even if I get paid for this ! On the other side, when the same people

see my name on some doc, they suddenly look at me as someone very

clever, which is completely stupid, given the fact that I'm probably

one of the smallest contributors of new code. But that's the way

people compare themselves and judge their fellow men, and it's not

going to change :-(
Git certainly has made things worse. We're not as careful as we used

to be about credits in the files since everything is in the changelogs.

And since it's easier to post 3 whitespace patches than 1 bug fix,

there are people posting stupid patches to get their name in a shortlog

and tell their friends.
If we want to get more manpower on bug hunting, we should really

think about what type of work we need, and simply assign credit

to people. Let's maintain scores for people doing painful bisect,

posting fixes for real bugs, etc... and get this file directly

linked to from kernel.org.
I'm really really sure we'd suddenly get more people working on

regressions and provide a fix for their oopses (or even their

friends'). Al...
[ message continues ]

People fix bugs when they realize that nobody else is going to do it for

them.

--

Stefan Richter

-=====-==--- -=-= =-=-=

http://arcgraph.de/sr/

--

That's partly true. But we don't need people to fix all bugs by themselves,

otherwise we might take more time trying to fix their own fixes. We most of

all need them to *work* on bugs, which is not the same. Actively

participating to tests and bug hunting is a very important activity. Let's

get the original code author propose a fix once the bug is pointed to.
Willy
--

Of course I speak for myself.  And I am absolutely open about my belief

that such _contribution_s_ need to be discouraged.  Actively.
Hell, a month ago I mentioned right-justifying text in comments as

"we'll never reach _that_" kind of pointless idiocy.  And there we

are, much closer to that than I ever expected.
I have nothing against contributors.  I *DO* have a lot against a very

specific class of contributions.  Exactly because they actively prevent

people from moving on to saner stuff.  Rule of the thumb: if a pointless

activity can be carried indefinitely long and creates an impression of

busy doing something, it ought to be discouraged.
Basically, something one could do as infinitely stretchable time-filler

when one _really_ doesn't feel like doing anything that might require

thinking.  Think of this situations like "I need to write the next

part of paper, but I just can't get around to starting it; anything

but that - let's rearrange the order of references, rearrange the

pencils, whatever".
And that is where I believe Ingo is wrong - dropping the level of acceptable

pointlessness of patches does *not* encourage meaningful contributions; it

discourages them.  Ladder doesn't become more accessible if you extend it

down into swamp; there's a reasonable starting level from which one _does_

go up.  It's impossible to define formally, but it's quite real and I'm
Sheesh, indeed.

--

There are good ways in which to communicate that and there are bad ways.
Look.  This has absolutely nothing to do with that patch.  Don't care,

doesn't matter, irrelevant, not even going to discuss it in this

context.
I have spoken with engineers both individual and within companies who

have developed and who plan to develop substantial kernel features.

I'm forever explaining to people why they should work to get that code

merged up.  One reason for their not yet having done so which comes up

again and again is apprehension at the reception they will receive.  In

public.  This problem appears to be especially strong in Asian

countries.  You have just made the situation worse.
But it's not just a self-interest thing.  It is inevitably and

unavoidably the case that when one senior kernel developer acts like an

arrogant hostile dickhead, we will all be increasingly regarded as

arrogant hostile dickheads.

--

It probably did make things marginally worse from that standpoint, but

the code style weanies also make things worse, so at least IMHO it's a

wash.
I'd suggest that the more aggressive public code reviews and the

perception that it is highly painful, time-consuming, and expensive to

get code merged up.  But of course we need that to maintain quality.

Even if we eliminated all code style weanies slapdowns, if a Asian

Engineer submits a patchset, and it gets (rightly) ripped to pieces by

Cristoph for all sorts of code quality problems, and by Al Viro

because it intrdoces tons and tons of deadlocks, we'll still have the

potential problem that the Asian engineer feels that he has shamed his

company and has to resign or will get fired by his management.  
The only way to solve that problem is either to change the perception

of Asian engineers and at their companies (and there has been some

success along that line that what is being attacked is the code, not

the submitter), and we could meet them halfway by offering to do an

initial code reivew privately so they don't have to feel that they are

getting publically humiliated.  (And there is a little of that going

on, informally, as well.)
So yes, it's a problem, and I'd agree if this was an gratuitously mean

code review.  i.e., the difference between, "isn't this a locking

hierarchy violation?" vs "Congratulations!  You've just completely

screwed up VM locking hierarchy, you idiot!".
People have been a bit frustrated by the stupid patches and people who

waste time with whitespace patches or running checkpatch.pl on random

files, so it's a bit understandable that they might slap down those

folks --- and I would hope that one of these Asian engineers would be

able to see the difference between a desperately needed slapdown and

the reception they might get when they submit a patch to be merged up.

(But if they are getting their patches ripped apart during the code

review, and that's causing them to lose face inside their company,

th...
[ message continues ]

You are joking right?
Thanks,

jaya

--

Yes. Their company's problem. I must say I'm getting rather sick of this

hiding behind culture. Does anyone think it's good for _anyone_ from any

culture to be publicly called upon their mistakes? Public is simply what

this development is and what makes it different from other types.
People who can't deal with it either grow up, go away or better still,

try their damndest to minimise mistakes to avoid the experience in the

first place. That last one in fact is one of the fundamental reason why

open source works.
Do feel free to call me a culturally insensitive clod -- I'll wear the

badge with pride...
Rene.

--

On Wed, 21 May 2008 22:38:04 +0200
Sigh.
There are kernel contributions which have not been submitted partly

because their developers are apprehensive about the way in which they

will be treated.
This is not theory.  It is not a guess.  It is not speculation.  It is

empirical observation.
We have a bad reputation.  I think it is largely undeserved nowadays,

because things have got a lot better.  But once a reputation has stuck,

it is hard to get it unstuck.
When I am on the podium and this problem is brought up by an audience

member (as regularly happens), my usual response is to say that things

have become better, that the problem was discussed at some length at

kernel summit a few years ago (as it was) and that people generally

agreed that it was a problem and that we should do better and that we

are doing better.
And we _are_ doing better.  On average.  But in this area, averages

do not count.  It's the maxima which are noticed.

--

Do note that in the above I did not suggest that the problem isn't real.

I'm just suggesting that it's not the _kernel's_ problem. The openness

adds significant value to the kernel. I'd say more value then would be

brought in by developers who now shy away from the process.
And yes, it's general openness. Noone is being ripped apart when they 
The actual case in point was a little odd though. I do not for a minute

believe that any serious developer is going to shy away from submitting

serious code due to an alignment patch getting a cynical slapdown.
Rene.
--

On Wed, 21 May 2008 23:08:29 +0200
Well you should.  One person makes a mistake and gets horridly

treated in public and this will make others fear the consequences of

any mistake they might make.
This could have been handled better, don't you think?

--

I myself tend be rather apprehensive about making an ass of myself in

public as well but the only thing I'm taking away from this particular

thread is that not everyone is going to appreciate argument alignment

patches. So I'll not submit those. Maybe I'll go to work on rewriting 
I'm not sure. Triggered myself into this thread mostly due to recent

pussy-footing around another culturally biased developer in a thread I

was in and the most definite impression I got there  was that if it had

been me, I'd have been mightely offended. No greater offense than people

believing they need to fight your fights for you.
Yes, by now I feel sorry for the poor chap that submitted the patch and

now has to sit through this thread and I'd definitely like you even more

than I already do (kissy!) if you'd just pick up the bloody thing but

telling the Linux citzenship that they can't be... open would be taking

too much away I feel.
Rene.

--

From: Andrew Morton <akpm@linux-foundation.org>
Al may not have expressed himself the most pleasant way, but I

do agree on some fundamental level with him.
There is way to much useless crap being discussed on this list, and

this is a list where the signal level is of an utmost importance for

the lists usability.
After deleting all of the noise posted here, I'm often too burnt out

to do real work with what's left and just delete that too. :-/

It's worse than the postmaster and list owner mail I process each

day for vger.kernel.org
Wouldn't you like me to instead have the energy left to review some

useful patches?
As one example, coding style is important and has it's place, but some

of these threads get way out of hand.  I don't give a flying crap how

people want to tab their code when I have some OOPS reports and bug

fixes to process!
The priorities are often all wrong, and this isn't the place for

inversed prioriries.  In that sense Al is totally right on the money.
At times you'd think there wasn't even a kernel newbies list.

--

I think, there is no "standard" on this. I personally do prefer indentation by tabs.

--

So do I, but that pales compared to how annoying I find patches that can

best be described as anal-retentive.  Let the person who writes the code

decide how to lay it out.

--