View source | Discuss this page | Page history | Printable version   

Bug Closing Guidelines



The process of checking a resolved issue as closed is the verification that the issue has been properly fixed and it is ready to be published.

This process has the following objectives:

Process of closing issues

To verify and close issues is one of the required steps of the Openbravo ERP release process. As a general overview the process is:

  1. RM freezes the repository and notifies the mailing list about it. Following the usual logic: all the commits done up to the 15th go in. And the freeze is done the 18th.
  2. After Support finishes the verification of all issues included they notify the mailing list about it. Also the release notes needs to be updated adding the most relevant issues fixed since the latest version.
  3. QA starts the update tests.
  4. If they are successful QA gives the greelight in the mailing list and RM publishes the release.

Issues to verify

The issues that needs to be verified are all the issues resolved that will be included in the new release that is about to be published. In other words, all the issues that have a related changeset in the changelog of the repository that is going to be used for the new release since the previous release must be verified.

To help in this task the reports published in include all the issues with a related changeset since the previous release. For example, in the report bellow the header Defects in Core are listed all the issues that have to be verified.

When and who closes issues

Issues must be closed as soon as possible they are resolved. All resolved issues go to the backlog of pending issues to closes. Before publishing a new version all issue fixes that go in that version must be verified and closed.

The person who closes the issue must be a person with experience in the area related to the issue and in the best case must be the person who reported the issue because this person has already experience in the issue reported and in most cases knows all the cases related to the issue apart what is explained in the issue report and also may already have an enviroment to test the issue.

For OBNetwork issues the support member that reported the issue will be the most accurate person to close the issue. For other issues it can be asked to the reporter to close the issue if available or if not possible, any member of the support team with experience o in the functional area related to the fix.

Verifications to be done to close an issue

From the issue report perspective the only change needed to do is to modify the status of the issue from "Resolved" to "Closed". But this status change involves that the following verifications have to be done by the person responsible:

The issue report

First the issue report needs to be properly resolved:

If the issue is not properly resolved the person in charge of closing the issue must ask the developer who resolved it to complete properly the issue resolution.

In the particular case of platform issues, it will be necesary to contact the person who fixed the issue or any other member of the platform team to understand properly what the issue is and how to test it properly.

The code that fixes the issue

After it has been checked that the issue report is properly resolved it has to be verified the correctness of the changeset that fixes the issue. To perform this task it will be helpful the diff of the changeset with all files and lines modified of the source code and the developer commit comment.

The aspects of the code that fixes the issue that must be verified are:

The functional behavior

Once the issue report and the code has been reviewed is the time to check that the issue is actually fixed. To do this it can be used the Openbravo ERP application deployed in the live builds servers: or a local instance built from the sources using the repository where the fix has been published. To execute properly the functional behavior verification it is helpful the developer notes "How to test the issue" and "Other areas affected".

The functionality and behavior that needs to be verified is:

Retrieved from ""

This page has been accessed 2,851 times. This page was last modified on 21 March 2011, at 17:35. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.