| |||||||||||||
Getting the right kind of contributionsGetting the right kind of contributionsPosted May 28, 2008 19:44 UTC (Wed) by NAR (subscriber, #1313)Parent article: Getting the right kind of contributions Submitting detailed bug reports, bisecting the kernel to find the patch that broke things, or testing proposed fixes go unrecognized Aren't most of the bugs related to specific hardware (-combination)? In this case the willingness to "hack the linux kernel" isn't enough, the possible contributor needs that hardware too.
(Log in to post comments)
Credits for testers and bisectors Posted May 28, 2008 20:18 UTC (Wed) by dmarti (subscriber, #11625) [Link] Two examples to look at: security advisories and newspaper bylines. Vendor security advisories are good at crediting the person who reported a security bug -- why not something similar for anyone who runs a "git bisect" session that results in a fix, or builds and tests a patch? The old-school newspaper rule is that if you see a byline of "Mary Example and Joe Random" then Mary was the one on-scene telling about the events to Joe, who actually wrote the copy. Maybe the kernel could do something similar for lengthy troubleshooting sessions. (And credit all whitespace fixes to whitespace-wanker@kernel.org and all spelling fixes to spelling-wanker@kernel.org ?)
Getting the right kind of contributions Posted May 28, 2008 21:18 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] There is of course a major difference between badly written code and trivial white spaces even though CodingStyle can cover both of them. In addition to that, it might be a valid thing to address in a review of new patches but drowning the list in such patches to known working code is asking for trouble.
|
|||||||||||||