Changes between Version 3 and Version 4 of ReportABug

Sep 10, 2007 2:01:23 PM (10 years ago)



  • ReportABug

    v3 v4  
    2424== What to put in a bug report ==
    26 The name of the bug-reporting game is: facts, facts, facts. Don't omit them because "Oh, they won't be interested…"
     26The Trac bug report system has various fields. Here's how to fill them in:
     28 * '''Your email or user name'''.  If you are logged in this will be filled in automatically.  If you are only logged in as ''guest'' then please consider replacing it with your email address. That way we can ask you questions, and you'll get email from Trac when something happens to your bug.
     30 * '''Short summary'''.  This is what appears in one-bug-per line lists, so try to make it as informative as you can.
     32 * '''Type''' says what kind of Trac ticket this is:
     33   * Bug: something wrong with GHC.
     34   * Feature request: something you would like GHC to do
     35   * Task: something we intend to do sometime (for use by GHC developers only)
     36   * Merge: job done, but must be merged to stable branch (for use by GHC developers only)
     38 * '''Severity'''.  How much this bug matters to you.
     40 * '''Full description'''.  This is where you describe your bug in details.  See "What information to provide" below.  Use the [wiki:TracWikiMisc wiki markup] in your description, especially `{{{` ... `}}}` brackets to mark up literal code.
     42 * '''Component''', '''Version''', '''Operating system''', '''Architecture''' all help to describe the setup that failed. Please pay particular attention to '''version''', which is the version of GHC that you are running.
     44 * '''Priority''' and '''Milestone'''.  Please do  not fill in these fields.   We use them to organise our priorities.  The '''severity''' field lets you say how important the bug is to you.
     46  * '''Assign to''', '''Difficulty''', '''Test case'''.  For use by GHC developers; please don't fill these in.
     51== Full description: what information to provide in the body of your bug report ==
     53The name of the bug-reporting game is: facts, facts, facts. Don't omit them because "Oh, they won't be interested…".
     55'''The absolutely key thing is that we must be able to reproduce the bug'''.  Without this, we are virtually helpless; we know there's a problem but we usually can make no progress with fixing it.  The easiset way to help us reproduce the bug is to provide us with a program that elicits it:
     56 * The smaller the better.  It costs you real work to "boil down" the bug from a big program to a small one, but the plain truth is that the easier the bug is to reproduce, and the smaller the test program (= smaller debug output), the more likely we are to fix it.
     57 * The fewer dependencies the better.  If your program depends on many libraries, it's harder for us to reproduce. 
     59One way to cut down programs is to replace library functions with definitions like
     61  displayWidget :: This -> IO That
     62  displayWidget = error "urk"
     64and thereby avoid the necessity for the supporting library. 
     66Here is a check-list of things to cover in your description:
     68 1. The source code of the program that shows the bug.  You can give the code inline, or attach a file, or attach a tarball.
    2869 1. What kind of machine are you running on, and exactly what version of the operating system are you using? (on a Unix system, `uname -a` or `cat /etc/motd` will show the desired information.) In the bug tracker, this information can be given in the "Architecture" and "Operating system" fields.
    2970 1. What version of GCC are you using? `gcc -v` will tell you.
    3071 1. Run the sequence of compiles/runs that caused the offending behaviour, cut-and-paste the whole session into the bug report. We'd prefer to see the whole thing.
    3172 1. Add the `-v` flag when running GHC, so we can see exactly what was run, what versions of things you have, etc.
     73 1. Add the `-dcore-lint` flag when running GHC.  This adds some significant internal consistency-checking, which often nails bugs early.
    3274 1. What is the program behaviour that is wrong, in your opinion?
    33  1. If practical, please attach or send enough source files for us to duplicate the problem.
    34  1. If you are a Hero and track down the problem in the compilation-system sources, please send us patches (either `darcs send`, plain patches, or just whole files if you prefer).
     77If you are a Hero and track down the problem in the compilation-system sources, please [wiki:WorkingConventions/Submissions send us patches].