Shared publicly  - 
Dear etiquette experts,

What is the proper amount of time to wait upon receiving an email containing  obviously incorrect statements about Linux kernel code before sending a "you have got to be kidding" email response.

Should I just hope the sender realizes their foolishness on their own and give them N hours to rescind the statement and fix up their insane patch and resend it, thereby giving them a grace period?  If so, what is the proper value for N?

Or is it fair game to let loose and channel up the Torvalds-like daemons within my keyboard, with the hope that it would actually do some good and they would learn from their mistakes?

Or do I just delete the message and hope they go away, realizing that no matter how many time I try to point out problems, someone new will come along to aggravate me and I need to just accept this as part of some distributed-denial-of-service attack by companies wanting to slow down the kernel development process, so by deleting it, stop the attack from happening?

Anticipating your response,

A grumpy kernel maintainer
Matej Csanyi's profile photoVee Grig's profile photoSarah Sharp's profile photoPeter Senna Tschudin's profile photo
If that doesn't help either, publicly ridicule.
1. /dev/null
2. man procmail
+Måns Rullgård, just telling "You are wrong" (or worse: "You're an dumbass") doesn't teach. You could go by explaining him with full details or at least point him in the right direction so he can learn on his own...
+David Cortarello but there comes a point at which doing this for everyone, all the time, becomes impossible. I'm reaching that point, especially for obvious problems that others should also be commenting on, and that people should be not doing in the first place (example, treating an atomic variable as a lock.)
Just forward all their emails to Stallman, he'll be glad to help them
IME, if you wait long enough someone else in the mailing list will flame them for you. You save time, and get entertainment value, 'cause now you know your planned snarky comments plus someone else's.

And you kept your karma and cool to be used when a worthwhile idiot comes along.
I would say, try to advertise the fact that you don't reply to balantly incorrect patches (because it doesn't scale, because you don't want to publicly ridicule people, whatever your actual reason is) and that your average turnaround time is M.  If after 2*M they have not seen activity from you, they ought to take that as a clue that something is seriously wrong with the submission and they should review it before thinking about resubmitting, or simply go back under the rock where they were hiding before.

Or something like that...

See?  I have redefined the problem!  Instead of figuring out N, you now get to figure out M, which should be easier.
Answering with a -EAGAIN or EINVAL  ? That could be fun.
Depends whether you personally are CONFIG_HZ_1000 or not.

I think Wolfgang Pauli said it best: "that's not's not even wrong."
I have found that the delete key is the always the best policy.  I think it was Confucius who said, "Better to keep quiet and let the people assume they are idiots instead of opening your mouth and saying something career limiting".  It was one of his more obscure quotes.
Why do I think the number 42 is relevant...
If its really really annoying, I would write the mail but not send. 

Get it off your chest, but not onto someone else's.

My drafts folder is filled with unsent bile written in reaction to foolish questions from the great unwashed of the software world.
Honestly, I channel all of my rage at the glibc wiki and then point people at the wiki. After approximately 4 years of this we have a great wiki and a new community :-)
Is it a repeat offender? Even Linus tends to not rip people into shreds (these days?) until they show themselves to lack a clue after repeated attempts to explain things or if there's more history of cluelessness in the past.

I'd send a mild "this doesn't make sense" reply pretty quickly, and if you really have to escalate to get the point across later on, then I guess that's your choice. But an "Uh, are you sure you're thinking about this the right way?" reply first with a chance for them to realize what they're misthinking might go a long way.

That being said, you deal with more vendors than probably any of us, and I know that tends to tax all sorts of patience. :)
You should craft up a Steve-Jobs-style one-line response.
+Olof Johansson repeat offender, despite trying to be nice numerous times, I think this is the 5th version of the patchset I've seen, and it's still not sinking in.
5th version of the patchset?

  ...Mother Mary
  comes to me
  speaking words of wisdom,
  let it be...
See if you can persuade Al Viro to maintain that code section and wait ?
+Greg Kroah-Hartman Hmm.. I'm a tad behind lkml reading at the moment, but if I happen to come across the offending patchset, I'll give it a proper review with the commentary it deserves.   Not sure if anybody takes me seriously or not though. ;)
Automate it, so by spending the same time of deleting it you can just point the guy to the right direction using +Helen S. example ^^;
+Helen S. I'd make the end of that read "where your work will be more easily integrated, such as in gardening." No offence to actual gardeners.
+Helen S. Sometimes, I'm amazed at how difficult it can be to find a "more straightforward problem" for some of these patch submitters.  We had one guy who was submitting spelling corrections for stuff that was properly spelled which added more errors than just the mis-correction, and other similar totally wrong stuff.  And the guy was at it for weeks, despite multiple maintainers telling him "English is obviously not a native language for you.  Please stop this".
The test could be simply surviving a Torvalds attack.
+Måns Rullgård The problem is that there's a lot more bozo programmers in the world than Torvalds has time to reply to.  That, plus reading Linus' postings to lkml it's pretty clear that he has a hard time getting excited to flame random idiots. His most vehement attacks are when something stupid gets posted by somebody that is well-known to know better (or at least should know better).  Witness some of his comments lately regarding udev and systemd maintainers. :)
I meant a Torvalds-style attack, not necessarily from the man himself.
+Helen S. pointing people to some simple project like gnu hello.c might be a little disparaging but might be entertaining. Jokes aside some teaching projects might be setup for this purpose only.
You don't have minions to do this kind of stuff for you? I'd have assumed you did. Maybe you might want to think about installing some trusted devs (aka minions)  underneath you to act as another level of filtering. 

But in general, I think after the 4th bad idea patch set start off by shaming the company if tis really egregious. If you get another one after that, then the individual.  
minions are excellent... it's fantastic when you can brainwash eager young minds so well that they argue your arguments for you and are even sometimes correct!
My general rule is if it is likely to mislead newbies (remember Wrongbot?) please say something sharp; if someone seems teachable say something polite, otherwise ignore.
I let myself flame once a year; just knowing this seems to give me more patience.

DaveM insists on telling people to post on the netdev mailing list.  A very valid policy, IMHO.
qtx qtx
I would say: N = 0 with response: "Please think(study the problem) more carefully before posting, You don't want to waste your time and I don't want to waste mine".  If the person doesn't get it then no response should follow.

Thinking 1000 times before saying something is required in this case. After all is a community work.

This way you don't give false hope. (some what Torvalds style) .
That's assuming their ego doesn't deserve to be hurt.
I'm not condoning personal attacks. Simply stating, factually, that a patch is wrong (and explaining why) is like a sledgehammer to some egos.
All I'm saying is that some egos are not worth protecting.
There's no one thing to do, but I think a nice way is to reply next morning in a brief manner and without emotions (i.e. not Linus style). If they stick to their guns, ignore going forward. You have a finite amount of time.
Filter their email to trash, notify them of that decision.
Maybe you should make a common mistakes page on and point them to it? That way you don't have to type the same long explanations over and over again.
+Greg Kroah-Hartman I would say as soon as possible:
There are problems in your patch, but unfortunately I dont have time to help you. Why don't you send it to kernel-janitors asking for help?
Add a comment...