<OPEN>: Register a JIRA issue
When you start a new project or if you find a bug, you can start your contribution by creating a JIRA issue. The issues creation process and field values that you need to specify according to the issue types are described in the ‘Issue Creation Procedure’ section below.
You can revert from any statuses of the issue to the status 'OPEN' as needed. In any status during the ongoing status (CONFIRMED, IN PROGRESS, REVIEW IN PROGRESS, REVIEWED), if you need to recheck the issue, press the 'Ask Confirmation/Reconfiguration' button to return the issue to 'OPEN' and specify the project maintainer as assignee.
In addition, if a problem occurs in the closed (‘CLOSED’ status) issue later, you can change the status of the issue back to 'OPEN' by clicking the 'Reopen Bug' button. Resolved (‘RESOLVED’ status) issues are changed to 'OPEN' and delivered to the project maintainer only when there is no developer in charge.
When creating an issue, it is recommended not to deal with multiple issues as one single issue, but to divide the issues into several issues as much as possible.
1. After logging in to CUBRID Jira website (jira.cubrid.org), click the orange 'CREATE' button at the top.
2. In the newly opened 'CREATE Issue' window, fill in each section as described in the following table and click the 'Create' button at the bottom.
The component is set in module unit. Components are organized in a hierarchical structure and are increasingly subdivided. You can select multiple components in an issue. The above table are the components available for each project-specific CUBRID project. As shown in the table, CUBRID includes SM, QP, JavaSP, DS, Utility, etc., and each module also includes multiple modules.
When creating an issue, select the relevant module that is known at that time. In the process of investigating an issue, you can additionally select module information related to the issue. For example, in the case of an issue that improves the Buffer Manager in the SM module, you can select CUBRID, SM, or Buffer when creating an issue, and if it affects the File and Lock module while the issue is in progress, you can additionally select the Disk/File AND Lock module.
For projects that affect multiple modules, such as CTE, TDE, JSON, and Java SP, you can create and configure a new component. If necessary, you can ask the project maintainer to create a new component.
When creating an issue, copy the following template according to the issue type and write the necessary items:
> You can add sections if needed. > If you do not need a section in the template, do not remove it and fill in with 'N/A'. > If the fields can not be filled out, write down 'TBD' and fill in the content when it is confirmed.
In the following template, three types of issue are displayed.
- Description: Issue Description
- Test Build: Detail the build version that shows the same format as Repro, Actual Result to commit number. For example, you can write:
CUBRID-11.0.0.0248-b53ae4aAffected version/s in the JIRA field displays only the Major and Minor versions, while you must enter the specific version name where the bug actually occurred, including Patch and Revision. For version name rules, refer to the Release/Version section. You can also specify the version of the OS you built.
- Repro: Enter the procedure to reproduce the bug. Rather than writing a description of bug reproduction, all procedures such as environment reproduction, schema creation, query execution, and utility execution should be written so that they can be reproduced by copy-paste.
- Expected Result: Expected results (expected results to be fixed)
- Actual Result: Current results (problematic results)
- Additional Information: If there is any additional material or content that can be helpful to understand the bug, please write it down.
- Description: Issue Description
- Specification Changes: Organize and write the specifications to be changed. It can be used for defining QA tests, writing manuals, etc.
- Implementation: Create design specifications, implementation concepts and details to address issues.
- Acceptance Criteria: Define behaviors/results that must be satisfied within the scope of the issue you have chosen while conducting design and implementation according to your requirements. This content is the basis for the completion to review the design/implementation. If undefined behavior/results are critical, design/implementation needs to be reviewed.
- Definition of done: Write down the criteria of the completion of the issue. You can write as the following example:
- Satisfies the Acceptance Criteria.
- Pass the QA test.
- Description: Write down the purpose and description of the work.