StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Before anything else: concentrating about the performance bug report, and getting it right (with repeatable benchmarks) will at least help you to get people to bother with the problem. Also submit the patch after testing it, but beware that your great patch might use the wrong approach, and that they might write a better one. Or that simply it may be great, but might need fixes to get accepted, that even happens with uber-guys. And don't think to email somebody privately, but refer to LKML or to the appropriate subsystem ML.</p> <p>I'd suggest you to read through all other answers, and all applicable material, before contacting kernel developers; and read the bibliography of SubmittingPatches as well. They might be harsh if you do it wrong. The kernelnewbies IRC chat is a good place for you to start, because they are for sure welcoming, even if sometimes the environment can be too newbie-like (not sure, I've not been there so much).</p> <blockquote> <p>It may be that I'm being overly optimistic in thinking someone the kernel world's never heard of can contribute, but I'd be interested to find out.</p> </blockquote> <p>It's not overly optimistic; not in itself at least. Abstracting from you (since I don't know your skills), what is more unlikely is that your patch will be accepted without modifications, or that it's written according to the right skills. But actually, if your patch is addressed to a smaller community, it may be much easier.</p> <p>From somebody with some experience (i.e. me), before considering the patch submission, describe the problem and why it affects other applications. Considerations like "this improves our performance", especially if you qualify (vaguely) as a vendor, won't have appeal on kernel developers.</p> <p>Especially, omit such statements:</p> <blockquote> <p>rendering our current implementation workable, but less than optimal.</p> </blockquote> <p>because this will buy you a "fix your code" recommendation immediately by most readers.</p> <p>If performance of an existing application (not written by you) is impacted, that's different. For instance, once Linus promptly paid attention to fixing in the kernel performance for screwed up code, because that code was part of make, even if he was proud of the code he had written and of the fact that he didn't need to do that exact fix. I.e., you need an application which everybody cares about, or a solution without disadvantages. So, stuff like:</p> <blockquote> <p>behavior from an another (very commonly used) application</p> </blockquote> <p>is good, as long as your usage of that application is not deemed unreasonable.</p> <p>Finally, if you refer to source code, they'll likely ask to see the interested section - think to license issues with your code, if they exist, and solve any of them beforehand if you want to answer them quickly.</p> <p>Btw, this is a partial account of my experience there: <a href="https://www.ohloh.net/accounts/Blaisorblade" rel="nofollow noreferrer">https://www.ohloh.net/accounts/Blaisorblade</a></p> <p>If you want, you can contact me to help you directly with a proposed mail, and CC me on the discussion. I'm quite busy, but I might find some more time :-).</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload