Bugs

From OdaWiki
Revision as of 15:35, 17 January 2019 by Ch0wW (Talk | contribs) (Good examples)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Why bother?

  • • This helps improve Odamex by making it more robust ;
  • • This will help improve your bugfinding and testing skills ;
  • • You will get mentioned in the credits/contributors list if your report was very helpful (i.e. fixed a major problem).

Bug Tester's Guide

You can contribute to Odamex by finding new bugs and testing to see if existing bugs have been resolved.

Resources

There are several resources open to you:

Things to do

If you are involved in testing, you should generally build Odamex in debug mode and run it from within a debugger to obtain helpful information.

Known bugs

If stuck for things to do, please browse through our bug list to see if any bug needs testing. This will usually become obvious if you read the bug comments. Test for the bug and post your own comments. Make sure you are running the latest Odamex code, from our Github repository.

New bugs

Read and search the bug list before you post new bugs. Chances are, the bug has already been noticed by someone else. Bugs you should report commonly include incompatibilities, vulnerabilities and crashes. Also report any major annoyances, unintuitive, malfunctioning and missing features. Be reasonable in your assessment and always include exact instructions needed to reproduce the bug.

How to report a bug

The Odamex Bug Tracker is an active list of issues. Look through the bugs to see if the bug you want to report is already listed. Please only post reproducible bugs, with steps to reproduce them.

What to include

For a crash, the following information should be included in your report (or as much as you can):

  • Debugger information including the callstack
  • • Steps to reproduce the crash (what you did to make it happen)
  • • Other information including WAD files, map, operating system, compiler used and configuration (being server config, etc)

If the bug appears to be new and did not appear in a previous svn revision, it would also be helpful to determine which revision caused the bug. You may need to do regression testing to work this out and include the revision at which the bug was introduced.

Good examples

  • • A textbook example is shown in Bug 163
  • • A good report is provided by Bug 116