1. 24 10月, 2016 1 次提交
  2. 15 2月, 2016 1 次提交
  3. 19 4月, 2013 3 次提交
  4. 16 4月, 2013 4 次提交
    • S
      Docs: Add info on supported kernels to REPORTING-BUGS. · 2c97a63f
      Sarah Sharp 提交于
      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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      2c97a63f
    • S
      Docs: Add "Gather info" section to REPORTING-BUGS. · 7883a250
      Sarah Sharp 提交于
      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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      7883a250
    • S
      Docs: Step-by-step directions for reporting bugs. · d60418bc
      Sarah Sharp 提交于
      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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      d60418bc
    • S
      Trivial: docs: Remove six-space indentation in REPORTING-BUGS. · 3b12c21a
      Sarah Sharp 提交于
      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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      3b12c21a
  5. 19 8月, 2009 1 次提交
  6. 08 2月, 2008 1 次提交
  7. 08 12月, 2006 1 次提交
  8. 11 9月, 2005 1 次提交
  9. 06 8月, 2005 1 次提交
  10. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4