I asked a friend to translate very common phrase into not very common in kernel communitey at least language, so that I could use it as a name release without insulting too sensitive people. Because this is not just a phrase, but words which clearly describes my feeling about linux kernel review and feedback process. And maybe somewhat about kernel itself.
This is the 10'th renewed DST release and third resend of the same code, I added comments, changed name and turned on and off some debug messages for the previous releases. The last public DST comment was received more than a month ago, and it concerned whitespace placement in the patch. Since than patch was sent 4 times including changed whitespaces and added documentation. And still no feedback. I ask for inclusion, but the first I want to implement a good idea. This can be proved in discussion, and since it does not happen with people directly added into To: list, I get this as there are no objections on the idea and implementation: either because none cares or patch is perfect.
To understand the roots of this issue, I made a simple experiment with the previous DST release. I added following lines into the patch to catch reviewer's eyes:
+ +ass licker +static char dst_name[] = "Successful erackliss screwing into"; +
As you may expect, this does not compile and thus was never read by the people who are subscribed to the appropriate mail lists. I got one private mail about this fact for the whole week. The same DST code (without above lines) was sent public first time more than month ago and was resent 3 times after that.
That's why I do not care about DST inclusion anymore. I do not care about its linux-kernel@ feedback.
I care about project, so if you use it, send mails directly to me and soon-to-be opened DST (there will be lots of mail lists for every project in active state) mail list, and problem will be fixed with the highest priority.
I /am/ a kernel hacker, and frankly people are busy, they have stuff they're working on, and reviewing other peoples patches is _hard work_. So perhaps there isn't a grand conspiracy it's just that people aren't sitting by their computers waiting to read your patches :)
and even wrote that multiple times, apparently skipping that part makes replies more tragic :)
If people do not have the time or wish to review, say that, and things are done.
When you talk to the person, and he does not answer after several tries, don't you think that something is not right? Things will be much clearer when you will get 'have no time to talk' or similar, don't you think?
Plus people suddenly have time to talk about whitespaces and codying style (number of messages in the DST whitespace flame was several times more than number of releases I made without single comment).
Not answering to the mail is a plain hiding: if I do not reply maybe next time I will not receive that mail. If do not want to review for some reason: say that or apply the patch. Do not want to apply? Say that. It is simple :)
Feedback is the engine of the progress, even when it is 'will not provide more feedback since have no time', since it is a progress by itself compared to blackhole silence.
spam was here
yo, спамеры подтянулись!
Он постоянно сыпется, не всегда успеваю вовремя удалять.
Hi zbr,
I'm not a kernel developer, but I find myself curious, how would you have expected anyone to respond after putting this stuff in your patch? It really isn't a good idea, and the only conclusions it is likely to lead to are those unlikely beneficial to you.
As much as I'm *certain* there are politics involved here (as there always is where there are >1 people), I can't help but think that if your code is of such technical excellence, solves a problem domain without causing damage (e.g. the inotify cookie overload), and generally does what it claims, then I can't bring myself to believe that a community as smart as the Linux guys would all ignore you unless there was good reason (perhaps one not disclosed here at all).
FWIW I love your stuff. Great benchmarks, great (and very entertaining!) blog, and great technology you can't find anywhere else.
I did not want to make some long-standing conclusions, but things themselfs moved into that state. It is not always the case, when my patches are ignored: this only happens when things come to the generic enough code, more specific areas like cryptography or network are very interesting and are much better 'organized' in that regard, that people want to work on problem (feature, issue, bug or whatever) and do not pretend that everything is good.
I'm definitely not something special, there are lots of people who suffer from that.
What I propose is to be fair with people who develop code. If someone was added to the copy, it was done with the purpose, so that person would comment on the code. If there is no time for that or do not care: do not afraid, say that, say that there is no time or interest. And next time this code is about to be sent, author will not add that person to the copy list. It is simple and it worked (I saw similar responses in netdev@ for example). I'm perfectly ok with the situation, when work is rejected because of something, I do not code for inclusion, but because I like the process, but sending something into the black hole is just a complete waste of time. That's why I'm frustrated about current situation, and that is why I will continue to develop things I like, but will not bother too much pushing it upstream.
I can't bring myself to believe that a community as smart as the Linux guys would all ignore you unless there was good reason (perhaps one not disclosed here at all).
If my code is bad, I want to know that, since by sending it upstream I kind of ask "is it good? and if so, please apply". Not answering is a disrespect, answering "I do not care" is fair.
Thanks for reading this pathetic rants :)
Hey Dude,
just wanted to let you know that I checked out POHMELFS and really like what I see so far. So please keep up the good work!
Thank you, I will roll out set of fixes soon, so you may want to try them if something does not work now.
...there just aren't enough people who have both the skills to do a good code review, and the time to do so. Some people poke around the edges and say "Please don't do that" if they notice something really odd (say, overloading a field that's used by inotify in certain situations), but sometimes it's just very hard to do a good review of a random patch. Especially if the reviewer is unfamiliar with the problem that's trying to be solved.
Look, you do good work, and it's frustrating to be ignored, I know, but none of that changes the fact that doing a *good* review of code is a hard, thankless job.
Pretend you're writing a paper for an academic journal. You wouldn't just submit a series of equations, would you? The more text you can supply explaining the problem space, explaining why you made the solution you did, will help you get better reviews. It means less that the reviewers have to guess, and more time for them to actually look at how you're solving the problem at hand.
Your respin of the inotify patches looked better, by the way. Though john really needs to be the one to take a look at it, and it's Thanksgiving week here in the states which means many people are gone for the week.
ray-lk at madrabbit dot org
I do not ask for immediate inclusion, I can work out problematic cases and want to discuss possible solutions. What I do want is a feedback from people who make decisions on the Linux kernel development roadmap.
Pretend you're writing a paper for an academic journal. You wouldn't just submit a series of equations, would you? The more text you can supply explaining the problem space, explaining why you made the solution you did, will help you get better reviews. It means less that the reviewers have to guess, and more time for them to actually look at how you're solving the problem at hand.
I provide description of the projects, its goals and features, as long as documentation in the code (and POHMELFS for example has really lots of data, more than lots of other filesystems in the kernel).
Andrew Morton did DST review once and spotted whitespace problems, lack of documentation and some minor things like kconfig dependency and kcalloc/kmalloc. Also some corner cases were spotted by Sven Wegener, Remy Ritchen and others.
Since then (more than a month since whitespace patches) - silence. I would like to get descriptive 'no' reply, if things are not good enough, but I get nothing. That's the main problem.
Review work is NOT thankless, since submitter (at least me) always open for discussion, since he sent a patch exactly for that reason, and critics (with suggestions) is helpful also. People who make reviews get attention and thankful feedback from the submitter in turn.
Inotify gets more attention, since I break other's code, and none likes that :)
My understanding of the kernel inclusion process is that you must have users supporting the inclusion of your code. People telling: « I'm using this, it works fine, it would be great if it was included ». This will show the kernel developers that there is some interest in your project outside from your personal interest.
I already wrote that perfectly valid OMFS filesystem, which was created for the real hardware (embedded video device) and had (although small) number of users world-wide was initially rejected by Andrew Morton. Because that adds maintenance burden.
There was a different project called kevent: there were users, which sent benchmarks and theirs experience to linux-kernel@, there were no kevent features in the kernel (and some of them are missed even now, 3 years later), and still I got zero responses to the same patches, and different implementation was added, without even looking at what I proposed.
This is called politics, and I hate that, so do not even try. And partially showed diff part may explain the things :)
Plus DST has users (at least I got responses that that worked and how to setup this and that, even in this blog there are such questions), there is a package in AltLinux Sisyphus system, although quite old.