Граф коммитов

14 Коммитов

Автор SHA1 Сообщение Дата
Manuel Pégourié-Gonnard 11f0090e26 Docs: fix missing word in REPORTING-BUGS
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>
2016-02-15 11:18:23 +01:00
Sarah Sharp b7ca36ae3b Docs: Move ref to Frohwalt Egerer to end of REPORTING-BUGS
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>
2013-04-18 16:55:09 -07:00
Sarah Sharp bf6adaf501 Docs: Add a tips section to REPORTING-BUGS.
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>
2013-04-18 16:55:08 -07:00
Sarah Sharp bc6bed481f 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>
2013-04-18 16:54:53 -07:00
Sarah Sharp 2c97a63f6f Docs: Add info on supported kernels to REPORTING-BUGS.
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>
2013-04-15 10:10:21 -07:00
Sarah Sharp 7883a250fe Docs: Add "Gather info" section to REPORTING-BUGS.
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>
2013-04-15 10:10:21 -07:00
Sarah Sharp d60418bce5 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>
2013-04-15 10:10:20 -07:00
Sarah Sharp 3b12c21ab3 Trivial: docs: Remove six-space indentation in REPORTING-BUGS.
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>
2013-04-15 10:10:19 -07:00
Joe Perches 503f7944fa REPORTING-BUGS: add get_maintainer.pl blurb
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-08-18 16:31:13 -07:00
J. Bruce Fields 3ab32df72b REPORTING-BUGS: cc the mailing list too
People should also cc relevant mailing lists when reporting bugs.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-07 08:42:17 -08:00
Randy Dunlap 4e229beff7 [PATCH] REPORTING-BUGS: request .config file
Add kernel .config file to REPORTING-BUGS.

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-07 08:39:42 -08:00
Tobias Klauser 9dcbb32f16 [PATCH] Spelling and whitespace fixes for REPORTING-BUGS
The attached patch fixes some spelling errors in REPORTING-BUGS and also
removes all trailing whitespaces.

Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch>
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-10 10:06:31 -07:00
Andrew Morton 30e835e366 [PATCH] REPORTING-BUGS: track regressions
Add a new record to the REPORTING-BUGS template: "Most recent kernel version
which did not have the bug:".  So we can spot regressions more easily.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-05 12:22:37 -07:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00