Bug Reporting Guidelines

Introduction

If you have found a bug or you want to request a feature enhancement a issue report is the way to bring the attention to the Openbravo community.

Openbravo ERP bug tracker is a database of bugs and feature requests for Openbravo ERP project. It helps developers keep track of issues and who is fixing them. Users can help our effort by making their bug reports clear and specific. The better your bug report, the easier it is to identify the cause, and fix it.

Before reporting a bug

Please, before reporting a new bug, make sure that:

• It is a bug. Ensure that your problem is a general problem and not due to your particular configuration. To check this, have a look at Openbravo ERP forums. If you are not sure that the behavior is correct, please post a comment in the most accurate forum.

• The bug has not been already reported. To check this, have a look at Openbravo ERP tracker. If you have new information about an existing bug, please post a comment on the first bug - do not open a new bug report.

• Use the latest version of the program. Before reporting a bug, make sure that you are using the latest version of Openbravo. This will minimize the chance of reporting a bug that has already been fixed.

Quick guide to writing good bug reports

Computer program problems are some times complex issues. Writing a good report makes it easier for everyone to understand the problem and find a solution. A good bug report always:

• is Reproducible: If the developers cannot reproduce it or conclusively prove that it exists, they probably will not be able to fix it, and move on to the next bug. Provide step-by-step instructions for reproducing the bug, and we will be able to fix it.

• is Specific: Try and figure out exactly what causes the problem. Do not report more than one issue in the same report. You should report each issue in a different bug report.

• Describes your environment. Include information about the versions of your operating system, database system, Apache, Java runtime, Tomcat and other components which Openbravo relies on for its execution.

• Provides a good summary. You should be as precise and clear as possible when you give a summary (also called title) to the bug report. For example, a summary like "program hangs" is a bad sample of a summary because it does not provide any indication of where or how the program fails.

• Includes all the bug description fields. It helps a lot when managing the bug reports that users fill up the Category and Product Version fields.

• Is not anonymous. Often developers need to contact the user to get additional information about the bug. If the bug reporter cannot be contacted, the developer may not have enough information to fix the bug.

Proposing a bug fix

If you are a software developer and you have found a solution for the problem that you are reporting, you also can help us providing a fix for the problem and attaching your solution to the bug report. You can use the svn diff to create a patch with the differences between the SVN repository and the local copy. Before submitting the patch, remember:

• Make sure that your local copy is up-to-date (using svn up).
• The path should only fix the described issue. A patch fixing several issues makes its review process more difficult.

Resolving an issue report

When a developer fixes a bug, he must change the issue status to RESOLVED. When you resolve a bug or a feature request report, you must always indicate how the issue has been fixed:

If the issue has been fixed, you must:

• Give a short explanation of the fix.
• Fill in the 'fixed in svn revision' field.
• Add a link to the revision number in Openbravo repository web interface (WebSVN). An example can be seen in bug 594.

The bug can also be resolved automatically, through the integration between Mantis and Subversion. The only thing needed is to use a specific syntax in the subversion commit.

Rejecting an issue report

If the issue has been rejected, you must indicate the reason why it has been rejected. For instance, the issue could be:

• Duplicated
• Out of date
• Not an issue

Recommended structure for the report

A report usually contains the follow structure:

• Environment description
• Exact steps to follow to reproduce the bug
• Any significant error by the application
• Screenshots that help understand and locate the problem

Sample Openbravo bug report

This is a sample bug report. Notice that it follows all of the indications that we have just described: it is reproducible, specific, provides a good summary, includes all the bug description fields and it is not anonymous.

This is a sample bug report. It does not describe a real Openbravo bug.

Parts and ideas of these guidelines were taken from Mozilla Bug Writing Guidelines