login
Search
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 be empty.
...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. --
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. --
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. --
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 ...
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. --
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. --
[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 - --
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. --
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 ...
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 --
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. :)
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
--
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
--
*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 --
- 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/
--
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 but this (even quite short) document could help I think.
|
| 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, ...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 --
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 --
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
--
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 --
Really. I'd go read some of the less maintained driver code for an afternoon. Alan --
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 --
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. --
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
--
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) --
On Thu, 22 May 2008, Jesper Juhl wrote: here you mean NACK not ACK David Lang --
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 --
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.org but this (even quite short) document could help I | > think. | | How about the following? | | --- | | From: Johannes Weiner <hannes@saeurebad.de> | Subject: [PATCH] CodingStyle: no more ...
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 one to ...
