From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
To: Rob Landley <rob@landley.net>
Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: [RFC 5/7] Docs: Expectations for bug reporters and maintainers
Date: Mon, 15 Apr 2013 10:33:34 -0700 [thread overview]
Message-ID: <412f8f434c32c557b8c17e73163d003b895e2e56.1366046390.git.sarah.a.sharp@linux.intel.com> (raw)
In-Reply-To: <cover.1366046390.git.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>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
---
REPORTING-BUGS | 42 +++++++++++++++++++++++++++++++++++++++++-
1 files changed, 41 insertions(+), 1 deletions(-)
diff --git a/REPORTING-BUGS b/REPORTING-BUGS
index c1f6e43..327b33b 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!
--
1.7.9
next prev parent reply other threads:[~2013-04-15 17:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-15 17:33 [RFC 0/7] Update REPORTING-BUGS Sarah Sharp
2013-04-15 17:33 ` [RFC 1/7] Trivial: docs: Remove six-space indentation in REPORTING-BUGS Sarah Sharp
2013-04-15 17:33 ` [RFC 2/7] Docs: Step-by-step directions for reporting bugs Sarah Sharp
2013-04-15 17:33 ` [RFC 3/7] Docs: Add "Gather info" section to REPORTING-BUGS Sarah Sharp
2013-04-15 17:33 ` [RFC 4/7] Docs: Add info on supported kernels " Sarah Sharp
2013-04-17 0:24 ` Rob Landley
2013-04-15 17:33 ` Sarah Sharp [this message]
2013-04-17 2:15 ` [RFC 5/7] Docs: Expectations for bug reporters and maintainers Rob Landley
2013-04-17 18:23 ` Sarah Sharp
2013-04-17 23:49 ` Rob Landley
2013-04-18 23:52 ` Sarah Sharp
2013-04-20 6:24 ` Rob Landley
2013-04-19 6:08 ` Greg KH
2013-05-01 15:26 ` Mark Brown
2013-04-15 17:33 ` [RFC 6/7] Docs: Add a tips section to REPORTING-BUGS Sarah Sharp
2013-04-15 17:33 ` [RFC 7/7] Docs: Move ref to Frohwalt Egerer to end of REPORTING-BUGS Sarah Sharp
2013-04-15 21:40 ` [RFC 0/7] Update REPORTING-BUGS Linus Torvalds
2013-04-16 1:47 ` Theodore Ts'o
2013-04-16 21:58 ` Sarah Sharp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=412f8f434c32c557b8c17e73163d003b895e2e56.1366046390.git.sarah.a.sharp@linux.intel.com \
--to=sarah.a.sharp@linux.intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rob@landley.net \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®