Docs: Step-by-step directions for reporting bugs.
authorSarah Sharp <sarah.a.sharp@linux.intel.com>
Sun, 14 Apr 2013 00:44:55 +0000 (17:44 -0700)
committerSarah Sharp <sarah.a.sharp@linux.intel.com>
Mon, 15 Apr 2013 17:10:20 +0000 (10:10 -0700)
commitd60418bce5a2afe4ea838cda6a59c74ba8837c3f
treeb6cd991f6d6969ca6da612f0c8b360a406e62c6a
parent3b12c21ab34c1057aa7f1cf73139215e12e89b6c
Docs: Step-by-step directions for reporting bugs.

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