|
|
<table style="border-collapse: collapse; border: none;">
|
|
|
<tr style="border-collapse: collapse; border: none;">
|
|
|
<td style="border-collapse: collapse; border: none;">
|
|
|
<a href="http://www.openairinterface.org/">
|
|
|
<img src="../images/oai_final_logo.png" alt="" border=3 height=50 width=150>
|
|
|
</img>
|
|
|
</a>
|
|
|
</td>
|
|
|
<td style="border-collapse: collapse; border: none; vertical-align: center;">
|
|
|
<b><font size = "5">OAI Software Alliance Ticket Policy</font></b>
|
|
|
</td>
|
|
|
</tr>
|
|
|
</table>
|
|
|
|
|
|
## Table of Contents ##
|
|
|
|
|
|
1. [New Feature Development](#1-new-feature-development)
|
|
|
2. [Existing Feature improvement](#2-existing-feature-improvement)
|
|
|
1. [Creation of an improvement ticket](#21-creation-of-an-improvement-ticket)
|
|
|
2. [Closure of an improvement ticket](#22-closure-of-an-improvement-ticket)
|
|
|
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. [Resolution of the issue](#33-resolution-of-the-issue)
|
|
|
3. [Closure of the issue](#34-closure-of-the-issue)
|
|
|
|
|
|
----
|
|
|
|
|
|
A ticket refers to a task that requires work. It may be
|
|
|
|
|
|
* A new feature development
|
|
|
* An existing feature improvement
|
|
|
* A bug being detected that needs a resolution
|
|
|
|
|
|
The latter 2 task types are using the Git Repository Issues tracker under GitLab or GitHub.
|
|
|
|
|
|
# 1. New Feature Development #
|
|
|
|
|
|
A new feature development is decided by the OSA Strategic Board with given scope, resources and timeline.
|
|
|
Timeline should be divided into intermediate milestones.
|
|
|
|
|
|
Usually development is tracked using one of the OAI development [Trello boards](https://trello.com/oaidev).
|
|
|
|
|
|
A feature branch is dedicated to the development as described in [Feature branches](policy/branch#2-feature-branches).
|
|
|
|
|
|
# 2. Existing Feature improvement #
|
|
|
|
|
|
Improvements may be:
|
|
|
* Performance enhancement
|
|
|
* Memory footprint or
|
|
|
* Processing speed-up
|
|
|
* Code Clean-Up
|
|
|
* Dead-code removal
|
|
|
* Beautifying task
|
|
|
* File tree organization
|
|
|
|
|
|
## 2.1. Creation of an improvement ticket ##
|
|
|
|
|
|
Templates are usually available to help at the creation. However the following information **SHALL** be provided.
|
|
|
|
|
|
* Short title
|
|
|
* Add a proper description of the requested task
|
|
|
* Indicate if the task is repository-wide
|
|
|
* Task **SHALL** be assigned
|
|
|
* Labels **SHALL** be added:
|
|
|
* At least the kind of improvement:
|
|
|
* <img src="../images/enhancement-label.png" />
|
|
|
* <img src="../images/code-cleanup-label.png" />
|
|
|
* If the improvement is not repository wide, indicate the functional part affected with a label
|
|
|
* for example: <img src="../images/mac-scheduling-label.png" />
|
|
|
* create a new label if needed
|
|
|
* A **END-DATE SHALL** be scheduled
|
|
|
* Under GitLab it is called 'due date'
|
|
|
* Under GitHub you have to use milestone
|
|
|
|
|
|
The Technical Committee regularly monitors the creation of issues and may ask the ticket creator to follow the creation rule.
|
|
|
|
|
|
A enhancement branch is dedicated to the development as described in [Feature branches](policy/branch#2-feature-branches).
|
|
|
|
|
|
## 2.2. Closure of an improvement ticket ##
|
|
|
|
|
|
Once all the improvements have been performed, verified and merge into `develop` branch, the issue **SHALL** be <img src="../images/closed-label.png" />.
|
|
|
If a branch has been created, it **SHALL** be deleted.
|
|
|
|
|
|
# 3. Bug Tracking #
|
|
|
|
|
|
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 ##
|
|
|
|
|
|
Templates are usually available to help at the creation. However the following information **SHALL** be provided.
|
|
|
|
|
|
* Short title
|
|
|
* Add a proper description of the found issue
|
|
|
* Indicate how to reproduce it --> It will be the skeleton on how to validate the fix
|
|
|
* Indicate the code version:
|
|
|
* Release TAG
|
|
|
* Branch
|
|
|
* Commit ID
|
|
|
* Labels **SHALL** be added:
|
|
|
* <img src="../images/bug-label.png" /> **SHALL** be present
|
|
|
* <img src="../images/new-label.png" /> 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
|
|
|
* Under GitLab it is called 'due date'
|
|
|
* Under GitHub you have to use milestone
|
|
|
|
|
|
The Technical Committee regularly monitors the creation of issues and may ask the ticket creator to follow the creation rule.
|
|
|
|
|
|
## 3.2 Assessment of the issue ##
|
|
|
|
|
|
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 changes the state label to <img src="../images/needs-info-label.png" /> 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).
|
|
|
* The Technical Committee changes the state label to <img src="../images/assigned-label.png" /> 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 <img src="../images/on-going-label.png" />.
|
|
|
|
|
|
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 <img src="../images/fixed-label.png" />.
|
|
|
* 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 <img src="../images/verified-label.png" />.
|
|
|
* If OK, the merge request approval should start another CI job.
|
|
|
|
|
|
## 3.4. Closure of the issue ##
|
|
|
|
|
|
Once the CI Job that is performed on the integration `develop` branch is done with the correct status, the Technical Committee shall:
|
|
|
|
|
|
* change the state label to <img src="../images/closed-label.png" />
|
|
|
* close the issue by itself
|
|
|
* delete the dedicated branch (`fix-XXXX-***`) |