Bug Reporting

From Open Watcom

Revision as of 18:23, 30 October 2008; view current revision
←Older revision | Newer revision→
Jump to: navigation, search

Note: Please read this whole page before entering bug reports.

There are not all that many Open Watcom developers, it is difficult to respond to all bug reports in a timely manner. Some of the reports are incomplete or do not reflect actual bugs. This causes time that could be used for improving Open Watcom to be used instead for answering questions that could have been avoided. To allow us to concentrate on fixing real bugs, and to allow more time for making improvements to the tools, we have written some guidelines that should be followed.

Please note that our bug reporting system is not a discussion or help portal. Often people report "bugs" that are really questions about how to use Open Watcom. It is better to first ask questions on the news groups and then only report bugs if the ensuing discussion makes it clear that a bug is actually present.

Contents

Is it really a bug?

Did you use an old version of Open Watcom? Make sure that you are using latest version, we provide much less support (assume no support) for older versions.

When you find a problem, the first thing to do is to make a minimal test case that demonstrates the problem. In some cases this is not easy, but once done it allows the development team to see the problem more clearly. Often by making a test case you will notice that the actual problem is in your code, and not in the tools being used.

You should also ask yourself, “Did I read the Open Watcom manual?” Perhaps something was written there about the issue at hand.

Sometimes you may trying to compile code from another compiler and get lots of warnings or errors. This might be because some language extension provided by the other compiler is not supported by Open Watcom. It might also be that the code was poorly written (non-portable), or that some needed feature is not yet implemented in Open Watcom. In these cases please study the corresponding language standards or official documentation. If you are not sure that you are correct on an issue, please use our news groups to discuss the issue with other people (See Front page/Community).

"I am sure that this is a bug"

Now that you are sure you have found a bug, the next thing is to make sure that there is not already an existing bug report. Please search Open Watcom bugzilla for existing reports, and if you find a match check if you can provide any additional information. You can also vote for the bugs to indicate that you also experienced the same problem.

If there wasn’t existing bug report the next thing is to make sure that you can reproduce the problem. Most commonly a test case is a best solution. A useful test case will contain complete instructions and all the needed files to allow our team to reproduce the problem. If your test case contains more than one file please make an archive (for example a ZIP-file). Please remove all files that are generated by the process to make test case small (for example do not include object files unless you are sure it is important to have those). If you send us binary files, please make sure they do not contain any viruses or other malware, usually providing the binaries does not even help to solve the actual problem.

Be sure to formulate your bug report in a way that our team can easily understand. Please remember that Open Watcom is a cross platform tool so make sure that you mention the environment you are using. For example you should state which Linux distribution you are using, for example, and which version of Open Watcom you are using. Also make it clear which tools you were using, and anything else that you think might be important. Make sure the bug report subject line contains a description of the actual problem and that bug report body contains all the important information.

Please spell check and re-read your bug report before sending it out. The less problems there are on understanding your text, the faster the problem will get fixed.

When you are sure that everything is filled out correctly, please submit the report.

"Oh no! There was no response to my report in timely manner!"

Well… The world is not perfect either. We have a limited number of contributors so we cannot handle all reports as quickly as one might wish. It might be that your problem is difficult one to solve. If you feel that you should have received a response then:

PLEASE DO NOT “BUMP” YOUR BUG REPORT. IT DOES NOT HELP A THING.

Instead, write a friendly message to our news group and reference your bug report in the message. Perhaps your report was inadvertently ignored, or nobody with needed knowledge had had time to look at it. Also keep in mind that none of the developers are being paid for the work being done to the project…

"What? Someone closed my bug report! And it wasn’t marked as fixed!"

When our developers close a bug report, they usually write some comment why they closed it, or perhaps your bug report contains comments that caused the bug report to be closed. Please do not re-open the bug report unless you are sure it should be reopened. Before doing this, use the news groups to discuss why the bug report was closed.

"Ok! My bug is finally marked as fixed!"

Congratulations! You did a good job of informing us about the bug and you made it possible for our team to fix the problem! Now you would most likely want to use fixed version of the tool. We do not usually make patches to releases, so when a next release is provided it should contain necessary bug fixes. However, there are build servers that perform automated building and testing of the current source repository. You may download current builds from them.

Personal tools