Bugs

Bugzilla and Bugs

This page is for notes on how to use Bugzilla to report and triage bugs. Dan Kegel has a similar page, and there's some information in the Wine User's Guide. There is also some generic information on writing good bug reports.

When to report a bug

When : You should report a bug when:

  • Wine doesn't run a program the same way as Windows does (e.g. crash) with the default Wine configuration (i.e. no dlls from Windows, or DllOverrides set).

  • You are using the latest version of Wine (See downloads for information on how to get the latest).

  • You tested with a clean Wine directory (default location: "~/.wine").

  • Your system isn't at fault (system hangs/lockups that require a system reboot are usually driver problems).
  • Your system has all the libraries that Wine needs (see Recommended Packages).

  • You haven't modified Wine in any way (i.e. you are using a prepackaged binary or built from source by doing: "./configure ; make depend ; make")
  • You have searched bugzilla, and the problem hasn't been reported already. Check the known issues as well.

  • Also search for the application in the AppDB and look at the bug links for that application, as it could be already reported.

How to report

How : Go to Bugzilla (http://bugs.winehq.org), login, and click Enter bug, then Wine.

  • Put the name of the application in the Summary field, followed by a short description of the error. eg

    • WinZip: crashes when extracting a zip archive
      Use a summary explaining the bug symptoms and the name of the program that displays them, not what you think the problem is, so that:
    • Users can find duplicates
    • The problem can be marked as solved by checking that the symptom is gone
    • The bug remains valid even if your analysis is incorrect
  • Describe the crash in the Comments field, specifically, how to make the crash happen. eg.

    • Wine crashes when I click on the Extract button on the toolbar in WinZip 10.

      If you have any clues as to what the problem is, write them in here. Don't paste too much information in the comments field, just what looks relevant. Do not paste backtraces or error logs in the comments field (attach them instead). For bugs related to graphics, sound, and hardware devices, be sure to write down what hardware and drivers you're using.

      Here is an example of what NOT to do

  • Provide a download link to a free version of the program that shows the bug if possible. e.g.
    • http://www.winzip.com/downwz.htm
  • Attach any backtraces or error logs to the bug. You have to Submit the bug first before you're given the option to attach files. Again, please do not paste backtraces or error logs in the comments field.

  • Set the severity to
    • Trivial for a UI glitch that doesn't affect running of a program

    • Minor for minor loss of functionality, or other problem where an easy workaround is present

    • Normal for an application crash or other issue

    • Major for major loss of functionality for a wide range of applications

    • Critical for a critical problem that prevents all applications from working

    • Blocker when development and/or testing work cannot be done

Severity levels above Normal should only be set by experienced users or bugzilla admins.

  • For the above example, the severity is Normal. In 99% of cases, the severity should be set to Normal or Minor. Please remember blocker does not mean "it blocks you from running a single app", and not being able to play a game does not count as critical.

  • After you submitted the bug, please add it to the appropriate AppDB page(s). If there is no entry in the AppDB for an application, it might be helpful to add one (though that is not required for the bug report).

Do's and Don't's

  • Do fill in keywords (download, installer, testcase, source, etc.) properly.

  • Don't ask when the bug will be fixed. If a fix is in progress, it'll likely be posted in the bug.

  • Do attach terminal output (don't paste output into a comment).

  • Don't change the reported version. It should reflect the earliest version of Wine that had the bug. Don't update it every time you test for the bug.

  • Do check on your bug every release or two and let us know if the bug is still present. If not, mark it fixed.

  • Don't close fixed bugs. We'll close it whenever the next release is made.

  • Do attach the bug to the correct application in the AppDB.

  • Don't cc yourself to bugs you have reported (there's no need).

Bug Day!

If you'd like to help triage bugs so our developers can focus on actual coding, please feel free to join in on a Bug Day. These are generally the first Monday after a new Wine release.

See Also

Bugs (last edited 2009-08-17 00:55:12 by AlexanderScottJohns)