Difference between revisions of "ReportingBugs"

From The Battle for Wesnoth Wiki
(Guidelines for reporting bugs)
Line 36: Line 36:
 
Needed information:
 
Needed information:
 
* What version of the game are you running?
 
* What version of the game are you running?
* Have you built (from sources) the game by yourself?
+
* 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 operating system are you using?
 
  What version/release of that operating system?
 
 
* Can you reproduce the problem? If you can please provide steps to do it.
 
* Can you reproduce the problem? If you can please provide steps to do it.
  
 
In-play problems:
 
In-play problems:
* If it is in-play problem that you can reproduce:
+
* 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:
 
Problems with scenarios:
* If it is a problem with a contributed scenario (like the ones on the
+
* 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:
 
Multiplayer out-of-sync errors:
* We need wesnoth stdout/stderr output from person who got the error
+
* 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.
 
* We need savegame from person who got the error.
 
* Savegame from some other player if possible.
 
* Savegame from some other player if possible.
* The person who got the error should report the bug,
+
* 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:
 
Segfault:
* In Unix you enable core dumps with running 'ulimit -c unlimited'
+
* 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
+
* Send us backtrace output of the core file (using 'gdb /path/to/binary /path/to/corefile', and inside gdb 'bt')
  console, core dumps will go to current working directory ('pwd')
+
* 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.
* Send us backtrace output of the core file
+
* 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.
  (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.
 
* 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.
 
  
 
Sending savegames, screenshots, coredumps, etc:
 
Sending savegames, screenshots, coredumps, etc:
Line 84: Line 67:
 
== Bug protocol ==
 
== Bug protocol ==
  
* When adding a new bug, please choose either "Bug" or "Feature Request"
+
* 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".
  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".
* We use the Status values "None" (awaiting action),
+
* A bug which is fixed is marked "Fixed" by a developer, probably the one committing the fix or reviewing it.
  "Fixed", "Won't Fix", "Invalid" (not a bug),
+
* A bug present in a release is marked "Closed" only upon a new release containing the fix.
  "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.
 
* A bug present in a release is marked "Closed" only upon a new release
 
  containing the fix.
 
 
* Any bug present only in [[WesnothCVS]] is marked "Closed" when it is fixed.
 
* Any bug present only in [[WesnothCVS]] is marked "Closed" when it is fixed.

Revision as of 17:02, 13 August 2005

Guidelines for reporting bugs

  • 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 searching 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):

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?
  • What operating system are you using? 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.

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.

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).
  • 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.

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')
  • Send us backtrace output of the core file (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.
  • 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.

Sending savegames, screenshots, coredumps, etc:

  • Please compress the files (bzip2, gzip, zip).
  • You can attach files if you submit your bug thru Savannah (512KB max size), else
  • Put them on some web or ftp server where we can download them.
  • You can attach files to forum posts.
  • As a last resort you can send them via email to: davidnwhiteATcomcastDOTnet

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".
  • A bug which is fixed is marked "Fixed" by a developer, 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.
  • Any bug present only in WesnothCVS is marked "Closed" when it is fixed.