summaryrefslogtreecommitdiff
path: root/REPORTING-BUGS
AgeCommit message (Collapse)Author
2016-10-24docs-rst: create an user's manual bookMauro Carvalho Chehab
Place README, REPORTING-BUGS, SecurityBugs and kernel-parameters on an user's manual book. As we'll be numbering the user's manual, remove the manual numbering from SecurityBugs. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-10-24REPORTING-BUGS: convert to ReST markupMauro Carvalho Chehab
- add a title to the document; - use :: before verbatim blocks; - add blank lines where required; - use protocol for URL references; - use a verbatim block for the bugs template; - add cross references to SecurityBugs. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-02-15Docs: fix missing word in REPORTING-BUGSManuel Pégourié-Gonnard
The kernel versions, not the bugs, are listed on kernel.org Signed-off-by: Manuel Pégourié-Gonnard <mpg@elzevir.fr> Cc: trivial@kernel.org Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-04-18Docs: Move ref to Frohwalt Egerer to end of REPORTING-BUGSSarah Sharp
The document is largely not the same as the original that was crafted from Frohwalt Egerer's document, but leave it in as a historical thank you footnote. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-04-18Docs: Add a tips section to REPORTING-BUGS.Sarah Sharp
Lots of grumpy maintainers would love to have annoying newbies and disorganized bug reporters read Eric S. Raymond's "How To Ask Questions The Smart Way". Simon Tatham's "How to Report Bugs Effectively" is also relevant. It's likely no one will bother to read these, but it does give maintainers something to point to. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-04-18Docs: Expectations for bug reporters and maintainersSarah Sharp
Outline how often it's polite to ping kernel maintainers about bugs, and suggest that kernel maintainers should respond to bugs in 1 to 5 business days. Emphasize that regressions, userspace breakage, and kernel crashes are exceptions to that rule. Suggest escalation to LKML and Linus if these bugs are ignored during the merge window. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-15Docs: Add info on supported kernels to REPORTING-BUGS.Sarah Sharp
One of the most common frustrations maintainers have with bug reporters is the email that starts with "I have a two year old kernel from an embedded vendor with some random drivers and fixes thrown in, and it's crashing". Be specific about what kernel versions the upstream maintainers will fix bugs in, and direct bug reporters to their Linux distribution or embedded vendor if the bug is in an unsupported kernel. Suggest that bug reporters should reproduce their bugs on the latest -rc kernel. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-04-15Docs: Add "Gather info" section to REPORTING-BUGS.Sarah Sharp
Add a sub-heading, and emphasize reproducibility. Suggest taking a picture of the oops message. (Did no one have cameras in 2006?) Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-04-15Docs: Step-by-step directions for reporting bugs.Sarah Sharp
REPORTING-BUGS is pretty disorganized. Bug reporters are likely to be in a frustrated, stressed frame of mind, so introduce methodical step-by-step directions for how to report bugs. Use titles so people can skim it if necessary. Slight changes in procedures: 1. Encourage people to report bugs to maintainers and sub-system mailing lists, not LKML at first. I've seen way too many people get lost in the noise because they didn't Cc the maintainer or proper mailing list. 2. Link to bugzilla.kernel.org, and let people know that some maintainers prefer bugs filed there vs. the mailing lists. (Perhaps we need an entry in MAINTAINERS for which is preferred?) 3. If someone doesn't know where to report a bug, encourage them to both file a bugzilla entry and email LKML. Their report is less likely to get lost if there's a bugzilla entry. Preserve text about reporting security bugs, and get_maintainer.pl. More will be added/modified in upcoming patches. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-04-15Trivial: docs: Remove six-space indentation in REPORTING-BUGS.Sarah Sharp
Other paragraph format docs in Documentation don't use paragraph indentations, so conform REPORTING-BUGS to that. Re-wrap the paragraphs, keeping the doc to a 74-character line length, since that's what the original seemed to use. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2009-08-18REPORTING-BUGS: add get_maintainer.pl blurbJoe Perches
Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-07REPORTING-BUGS: cc the mailing list tooJ. Bruce Fields
People should also cc relevant mailing lists when reporting bugs. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-12-07[PATCH] REPORTING-BUGS: request .config fileRandy Dunlap
Add kernel .config file to REPORTING-BUGS. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-10[PATCH] Spelling and whitespace fixes for REPORTING-BUGSTobias Klauser
The attached patch fixes some spelling errors in REPORTING-BUGS and also removes all trailing whitespaces. Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch> Signed-off-by: Domen Puncer <domen@coderock.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-05[PATCH] REPORTING-BUGS: track regressionsAndrew Morton
Add a new record to the REPORTING-BUGS template: "Most recent kernel version which did not have the bug:". So we can spot regressions more easily. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!