Eric Lee / smarc-fsl-linux-kernel

15 Feb, 2016

1 commit

19 Apr, 2013

3 commits

  • b7ca36ae3   Docs: Move ref to Frohwalt Egerer to end of REPORTING-BUGS ... Browse Code »

    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 Sharp
     
  • bf6adaf50   Docs: Add a tips section to REPORTING-BUGS. ... Browse Code »

    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 Sharp
     
  • bc6bed481   Docs: Expectations for bug reporters and maintainers ... Browse Code »

    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
    Acked-by: Linus Torvalds

    Sarah Sharp
     

16 Apr, 2013

4 commits

  • 2c97a63f6   Docs: Add info on supported kernels to REPORTING-BUGS. ... Browse Code »

    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 Sharp
     
  • 7883a250f   Docs: Add "Gather info" section to REPORTING-BUGS. ... Browse Code »

    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 Sharp
     
  • d60418bce   Docs: Step-by-step directions for reporting bugs. ... Browse Code »

    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 Sharp
     
  • 3b12c21ab   Trivial: docs: Remove six-space indentation in REPORTING-BUGS. ... Browse Code »

    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 Sharp
     

19 Aug, 2009

1 commit

08 Feb, 2008

1 commit

08 Dec, 2006

1 commit

11 Sep, 2005

1 commit

06 Aug, 2005

1 commit

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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!

    Linus Torvalds