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>

- 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>

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>

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>

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>

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>

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>

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>

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>

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>