diff options
| author | Sarah Sharp <sarah.a.sharp@linux.intel.com> | 2013-04-13 17:44:55 -0700 |
|---|---|---|
| committer | Sarah Sharp <sarah.a.sharp@linux.intel.com> | 2013-04-15 10:10:20 -0700 |
| commit | d60418bce5a2afe4ea838cda6a59c74ba8837c3f (patch) | |
| tree | b6cd991f6d6969ca6da612f0c8b360a406e62c6a /security | |
| parent | 3b12c21ab34c1057aa7f1cf73139215e12e89b6c (diff) | |
| download | linux-0-day-d60418bce5a2afe4ea838cda6a59c74ba8837c3f.tar.gz linux-0-day-d60418bce5a2afe4ea838cda6a59c74ba8837c3f.tar.xz | |
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>
Diffstat (limited to 'security')
0 files changed, 0 insertions, 0 deletions