aboutsummaryrefslogtreecommitdiff
path: root/REPORTING-BUGS
diff options
context:
space:
mode:
authorSarah Sharp <sarah.a.sharp@linux.intel.com>2013-04-13 19:30:48 -0700
committerSarah Sharp <sarah.a.sharp@linux.intel.com>2013-04-18 16:54:53 -0700
commitbc6bed481ff3fbe2050f4290f59d27fad30b62a7 (patch)
tree26419cbcc1508a8bc04f42d9096b967c2ca1bc65 /REPORTING-BUGS
parent2c97a63f6fec91db91241981808d099ec60a4688 (diff)
Docs: Expectations for bug reporters and maintainers
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>
Diffstat (limited to 'REPORTING-BUGS')
-rw-r--r--REPORTING-BUGS42
1 files changed, 41 insertions, 1 deletions
diff --git a/REPORTING-BUGS b/REPORTING-BUGS
index c1f6e43f06f..327b33b43d6 100644
--- a/REPORTING-BUGS
+++ b/REPORTING-BUGS
@@ -117,4 +117,44 @@ summary from [1.]>" for easy identification by the developers.
[X.] Other notes, patches, fixes, workarounds:
-Thank you
+Follow up
+=========
+
+Expectations for bug reporters
+------------------------------
+
+Linux kernel maintainers expect bug reporters to be able to follow up on
+bug reports. That may include running new tests, applying patches,
+recompiling your kernel, and/or re-triggering your bug. The most
+frustrating thing for maintainers is for someone to report a bug, and then
+never follow up on a request to try out a fix.
+
+That said, it's still useful for a kernel maintainer to know a bug exists
+on a supported kernel, even if you can't follow up with retests. Follow
+up reports, such as replying to the email thread with "I tried the latest
+kernel and I can't reproduce my bug anymore" are also helpful, because
+maintainers have to assume silence means things are still broken.
+
+Expectations for kernel maintainers
+-----------------------------------
+
+Linux kernel maintainers are busy, overworked human beings. Some times
+they may not be able to address your bug in a day, a week, or two weeks.
+If they don't answer your email, they may be on vacation, or at a Linux
+conference. Check the conference schedule at LWN.net for more info:
+ https://lwn.net/Calendar/
+
+In general, kernel maintainers take 1 to 5 business days to respond to
+bugs. The majority of kernel maintainers are employed to work on the
+kernel, and they may not work on the weekends. Maintainers are scattered
+around the world, and they may not work in your time zone. Unless you
+have a high priority bug, please wait at least a week after the first bug
+report before sending the maintainer a reminder email.
+
+The exceptions to this rule are regressions, kernel crashes, security holes,
+or userspace breakage caused by new kernel behavior. Those bugs should be
+addressed by the maintainers ASAP. If you suspect a maintainer is not
+responding to these types of bugs in a timely manner (especially during a
+merge window), escalate the bug to LKML and Linus Torvalds.
+
+Thank you!