UserAgent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 IP: 198.54.202.234 URI: http://wesnoth.slack.it/?ReportingBugs - - - - - Index: ReportingBugs =================================================================== RCS file: /home/wesnoth/cvsroot/wikiroot/ReportingBugs,v retrieving revision 1.22 diff -u -r1.22 ReportingBugs --- ReportingBugs 22 Apr 2005 05:11:37 -0000 1.22 +++ ReportingBugs 21 Jul 2005 13:02:17 -0000 @@ -1,14 +1,40 @@ ||Guidelines for reporting bugs|| -Please login to Savannah before reporting bugs so we get your contact -information just in case we need to ask more -details, and so you will be notified of changes to your bug reports. -An account at Savannah is free. +* First, please make sure the bug you are reporting has not already + been fixed (consult http://changelog.wesnoth.org/ to see the + history of changes to the game). +* If it hasn't been fixed yet, please check + that the bug hasn't already been reported, by using + https://savannah.nongnu.org/bugs/?func=search&group=wesnoth + to search the bugs database. +* If your bug or feature request hasn't been fixed and has not + yet been submitted, please go ahead and report it. +* Please post only one bug per bug report. + If you have multiple bugs that are related, + you can cross reference them. + +Note that feature requests should usually be discussed on the +forums first, or they will generally be ignored until there +is evidence that such a feature would be generally liked. + +Keep bug reports to the point, and make sure your bug is easily +reproducible given the information you provide. +Clearly written, reproducible single bug reports will get +attention before those reports that mix several different +bugs into one report, or that are incomprehensible. If there is already an existing bug report, do not hesitate to add a comment with your details - this way we know when some bug is getting "popular". +||Please|| login to Savannah before reporting bugs. An account +at Savannah is free and takes very little time to set up. +You can submit anonymous bug reports, but then you will have to keep +an eye on the bug report in case developers ask for clarification, +which will delay your bug being fixed. If you login, you will +receive notifications of any changes to your bug reports, which +speeds things up considerably. + Bugs can be reported on (first one preferred): * Wesnoth bugs page on Savannah - http://savannah.nongnu.org/bugs/?group=wesnoth * Shortcut to previous - http://bugs.wesnoth.org/ @@ -18,43 +44,43 @@ Needed information: * What version of the game are you running? * Have you built (from sources) the game by yourself? -gcc/g++ version? SDL library versions? + gcc/g++ version? SDL library versions? * What operating system are you using? -What version/release of that operating system? + What version/release of that operating system? * Can you reproduce the problem? If you can please provide steps to do it. In-play problems: * If it is in-play problem that you can reproduce: -save the game, send the savegame to us with details how to reproduce -the problem from the savegame. + save the game, send the savegame to us with details how to reproduce + the problem from the savegame. Problems with scenarios: * If it is a problem with a contributed scenario (like the ones on the -Campaign Server), please report the problem to the maintainer of the scenario, -not as a bug in Wesnoth itself. Bugs in the MainlineScenarios should -be reported in the bug tracker. + Campaign Server), please report the problem to the maintainer of the + scenario, not as a bug in Wesnoth itself. Bugs in the MainlineScenarios + should be reported in the bug tracker. Multiplayer out-of-sync errors: * We need wesnoth stdout/stderr output from person who got the error -(if you started wesnoth in terminal stdout/stderr is in that terminal). + (if you started wesnoth in terminal stdout/stderr is in that terminal). * We need savegame from person who got the error. * Savegame from some other player if possible. * The person who got the error should report the bug, -other players can then add their savegames to that bug. + other players can then add their savegames to that bug. Segfault: * In Unix you enable core dumps with running 'ulimit -c unlimited' -on console and then starting wesnoth from that same -console, core dumps will go to current working directory ('pwd') + on console and then starting wesnoth from that same + console, core dumps will go to current working directory ('pwd') * Send us backtrace output of the core file -(using 'gdb /path/to/binary /path/to/corefile', and inside gdb 'bt') + (using 'gdb /path/to/binary /path/to/corefile', and inside gdb 'bt') * In NT based OS's (including Win2k, XP) you enable/configure -core dumps by running 'drwtsn32', the location of the -dumps can be changed there. + core dumps by running 'drwtsn32', the location of the + dumps can be changed there. * In MacOS X, you can enable Crash Reporter -- the output is a backtrace. -Run Applications -> Utilities -> Console to see log output. -See http://www.mozilla.org/mailnews/osxinfo.html for information on how -to enable Crash Reporter. + Run Applications -> Utilities -> Console to see log output. + See http://www.mozilla.org/mailnews/osxinfo.html for information on how + to enable Crash Reporter. Sending savegames, screenshots, coredumps, etc: * Please compress the files (bzip2, gzip, zip). @@ -66,12 +92,12 @@ ||Bug protocol|| * When adding a new bug, please choose either "Bug" or "Feature Request" -as its Category; it may not be noticed if you leave the Category as "None". -* We use the Status values -"None" (awaiting action), "Fixed", "Won't Fix", "Invalid" (not a bug), -"Works For Me" (unreproducible), or "Need Info". + as its Category; it may not be noticed if you leave the Category as "None". +* We use the Status values "None" (awaiting action), + "Fixed", "Won't Fix", "Invalid" (not a bug), + "Works For Me" (unreproducible), or "Need Info". * A bug which is fixed is marked "Fixed" by a developer, -probably the one committing the fix or reviewing it. + probably the one committing the fix or reviewing it. * A bug present in a release is marked "Closed" only upon a new release -containing the fix. + containing the fix. * Any bug present only in WesnothCVS is marked "Closed" when it is fixed.
_______________________________________________ Wesnoth-wiki-changes mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/wesnoth-wiki-changes
