... | ... | @@ -21,7 +21,8 @@ |
|
|
3. [Bug Tracking](#3-bug-tracking)
|
|
|
1. [Creation of an issue ticket](#31-creation-of-an-issue-ticket)
|
|
|
2. [Assessment of the issue](#32-assessment-of-the-issue)
|
|
|
3. [Closure of the issue](#33-closure-of-the-issue)
|
|
|
3. [Resolution of the issue](#33-resolution-of-the-issue)
|
|
|
3. [Closure of the issue](#34-closure-of-the-issue)
|
|
|
|
|
|
----
|
|
|
|
... | ... | @@ -77,9 +78,16 @@ A enhancement branch is dedicated to the development as described in [Feature br |
|
|
|
|
|
## 2.2. Closure of an improvement ticket ##
|
|
|
|
|
|
Once all the improvements have been performed, verified and merge into `develop` branch, the issue **SHALL** be closed.
|
|
|
If a branch has been created, it **SHALL** be deleted.
|
|
|
|
|
|
# 3. Bug Tracking #
|
|
|
|
|
|
Issues are found by OAI users, contributors, integrators.
|
|
|
Issues (or bugs) are found by OAI users, contributors, integrators.
|
|
|
|
|
|
The life of a bug is described by the following picture:
|
|
|
|
|
|
<img src="../images/bug-life.png" width = "475" height = "344" align = "center" />
|
|
|
|
|
|
## 3.1. Creation of an issue ticket ##
|
|
|
|
... | ... | @@ -94,6 +102,7 @@ Templates are usually available to help at the creation. However the following i |
|
|
* Commit ID
|
|
|
* Labels **SHALL** be added:
|
|
|
* Bug **SHALL** be present
|
|
|
* **NEW** label **SHALL** be set
|
|
|
* If the issue is located, indicate the functional part affected with a label
|
|
|
* create a new label if needed
|
|
|
* A **NEED-DATE SHALL** be added
|
... | ... | @@ -104,16 +113,46 @@ The Technical Committee regularly monitors the creation of issues and may ask th |
|
|
|
|
|
## 3.2 Assessment of the issue ##
|
|
|
|
|
|
The Technical Committee regularly monitors the issue list.
|
|
|
It will assess if the reported issue is valid. The reasons to decline an issues are (non-exclusive):
|
|
|
The Technical Committee regularly monitors the issue list.
|
|
|
|
|
|
It will first assess if all the required information is present (as defined in the previous section).
|
|
|
|
|
|
* The bug report does not have all the required labels.
|
|
|
* The bug report has insufficient information to act upon.
|
|
|
* The Technical Committee change the state label to 'NeedsInfo' in the issue report
|
|
|
* If enough time passes and no new information is provided, the bug may be closed by default, as one of the No-Action states.
|
|
|
|
|
|
It will assess if the reported issue is valid. The reasons to decline an issue are (non-exclusive):
|
|
|
|
|
|
* Incorrect use case
|
|
|
* Not reproducible
|
|
|
* Infeasible
|
|
|
* The changes that are needed to address the issue are not reasonably possible.
|
|
|
* Duplicate
|
|
|
* Bug fixed in later version
|
|
|
* User / Contributor shall be warned to the version to use/merge with.
|
|
|
|
|
|
Once the issue is deemed valid by the Technical Committee, it shall assign someone to it.
|
|
|
A dedicated fix branch is dedicated to the development as described in [Bug-fix branches](policy/branch#3-bug-fix-branches).
|
|
|
Once the issue is deemed valid by the Technical Committee, it shall assign someone to it.
|
|
|
|
|
|
* A dedicated fix branch is dedicated to the development as described in [Bug-fix branches](policy/branch#3-bug-fix-branches).
|
|
|
* The Technical Committee change the state label to 'Assigned' in the issue report
|
|
|
|
|
|
## 3.3. Resolution of the issue ##
|
|
|
|
|
|
Once the assignee starts working on it, he/she **SHALL** change the state label to 'On-Going'.
|
|
|
|
|
|
Then the assignee implements a solution that should corresponds to one or several commits onto the `fix-XXXX-***` branch.
|
|
|
|
|
|
* The last commit message **SHALL** has the Issue ID as reference.
|
|
|
* The assignee **SHALL** change the state label to 'Fixed'.
|
|
|
* The assignee creates a Merge Request with the proper information.
|
|
|
|
|
|
By creating a Merge Request, the OAI Continuous Integration should be automatically triggered and provides a status within the merge request web interface. Emails could be also sent to assignee and integrators.
|
|
|
|
|
|
Based on the status, the Technical Committee decides to accept or not the Merge Request:
|
|
|
|
|
|
* The Technical Committee **SHALL** change the state label to 'Verified'.
|
|
|
* If OK, the merge request approval should start another CI job.
|
|
|
|
|
|
## 3.3. Closure of the issue ##
|
|
|
## 3.4. Closure of the issue ##
|
|
|
|