How to help: Triage Bugzilla problem reports

Some saved searches for Bugzilla to start triaging on:All unconfirmed bugs that have a 'download' keyword: Link

All open bugs that have a 'download' keyword, but no activity in 90 days. Probably could use a quick verification to see if still a bug or not: Link

All bugs that have not had any activity in 6 months. These should be tagged as 'abandoned?', but not closed yet: Link

*Note, some bugs that have not had activity should not be tagged 'abandoned?'. Use your judgement. Bugs that have been around for years and are large scale projects should be left alone. Bugs that are a year or two old, and about some program that a user reported not working and stopped provided information should be tagged. Use your judgement.*

All bugs with 'abandoned?' keyword that have not had activity in 6 months. These should probably be closed as abandoned: Link

Some general Bugzilla guidelines:

Mark a bug as fixed if the patch that fixes the bug has been committed to git.

Mark a bug as invalid if the bug is not a wine bug, is an application bug, uses native dll's when not asked to, uses IES4Linux, running from a windows partition, etc.

Mark a bug as closed if the bug is fixed in the latest binary release of wine.

Mark a bug as confirmed if a triager can reproduce, or multiple individuals have reproduced the bug.

Mark a bug as abandoned if there has been no activity in 6 months, after a request was made for more information/testing/etc.

What to do with a fresh bug:

Many times, newly reported bugs are not in a condition that most developers will be able to work with. That's where triaging comes in. Start by making sure the bug is not a duplicate of another bug. Try searching for the program's name, or the error reported. Also take a look at the KnownIssues page to make sure it's not a commonly reported issue. If so, mark it as a dupe. If not, fill in any missing information if possible, or request it from the reporter.

• Product - Should be Wine, unless it's a website bug. On the rare occasion it is mislabeled as a website bug instead of a Wine bug, change it.
• Component - Often wrong. If you can determine the correct component, fix it. If not, change it to wine-misc.
• Hardware - If not filled in, ask the reporter to do so. Most likely PC, but since 64-bit is on the rise, it could be PC-x86-64. In addition, some bugs seem to be related to 64-bit processors, so this is important.
• O/S - Most likely Linux, but ask the reporter to fill it in if it isn't already.
• Version - If it is an older version (not from Git or the latest binary version), ask the reporter to upgrade and retest. If it is blank, ask the reporter to fill it in.
• Priority - Don't worry about this one. Should be at P2. If not, change it back. Let the developers change this one.

• Severity - People often mislabel this one, thinking any issue they have is automatically a blocker. Use the guide here to determine the proper severity.

• Target Milestone - Should be blank, unless you feel this bug should be a 1.0 target.
• URL - If the program can be downloaded somewhere, put the URL here. If not, put the AppDB page or the vendor's website, if available.
• Whiteboard - Leave blank.

• Keywords - Use the list of valid keywords here to fill this in. The most commonly used are download, installer, regression, and source.

• Difficulty - Leave blank, unless you intend to fix this bug and know how long it will take you.
• Depends on - Leave blank, unless you know that this bug depends on some other bug.
• Blocks - Leave blank, unless you know that this bug blocks some other bug.

Verifying Bugs:

After filling in any missing information, it's a good idea to try to verify the bug if you can. Be sure to start with a clean wine prefix. If the program can be downloaded, download and test for the problem. If you don't know how to test for it, ask the reporter to give a step-by-step guide to reproduce the issue. If you can reproduce the error, then confirm the bug. If not, ask the reporter to retry in a clean .wine directory. If you can reproduce it, you can help the developers further by trying to narrow down the issue.

Start by trying to see if any native dll's can help. Running the program with 'WINEDEBUG=+loaddll program.exe' will tell you what dll's were loaded. Try to see if the native dll(s) fixes the issue. If so, uploading a log with a trace of that component will usually help whatever developer takes the bug. If native dll's do not help, running the program with 'WINEDEBUG=+relay,+tid,+seh program.exe' or 'WINEDEBUG=warn+all program.exe' will usually reveal some clues.

See Also

Gecko for instructions on having a local copy of the gecko browser to save downloading it each time you create a fresh .wine

Regression Bugs:

If the bug is a regression from a previous version, have the reporter retest in a clean .wine directory. If still present, have them run a Regression Test. Once they've found the patch, add the author of the patch to the CC, if they did not.