Open: Register a JIRA issue

When starting a new development item or discovering a bug, you create a JIRA issue. The issue creation process and the items to be filled out are described in the issue creation procedure. Initially, issues are set to the Open status, but to gain approval through triage, you must complete the issue creation and then press the "To Triage" button to forward the issue to the project maintainer.

Subsequently, it is possible to revert from any status back to Open state as needed. During the progression of an issue, if reconfirmation of the issue is necessary at any stage Confirmed, Analysis, Develop, Handover, Resolved), pressing the "Ask Reconfirmation" button will automatically revert the issue’s status to Open and assign it back to the project maintainer. Additionally, even completed (Closed) issues can be reopened if problems arise later by pressing the "Reopen Bug" button, changing the issue's status back to Open.

When creating an issue, it is advisable not to address multiple problems within a single issue. Instead, it is preferable to break down the problem into smaller parts and handle them as separate issues.

Issue Creation Procedure

1. After logging in to CUBRID Jira website (jira.cubrid.org), click the "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.

Field	Description
Project	Select a project category. · CBRD: CUBRID CAS, DB SERVER · APIS: Driver such as CCI, JDBC · CUBRIDMAN: CUBRID manual · TOOLS: CUBRID Manager, CUBRID Migration Tool · CUBRIDQA: QA system, QA test case
Issue Type	Select the type of issue. For more information, refer to the 'Issue Type' section below.
Summary	Enter the title of the issue.
Priority	The default setting is ‘Minor’. However, at the time of triage, the project maintainer can change the level of priority if necessary.
Components	Specifies the category of module units or project units. Details are described in the 'Component' section below.
Description	Fill in by referring to the ‘issue content template’ section below.
Affects version/s	Fill in the version in which the issue creator found bugs. * NOTE: When registering a bug issue, you need to check not only the latest develop version but also the previous released version. If a bug occurs in a previous release version, add that version to the Affected Version(s) item.
Label	Type any registered label. * Label managed by project maintainer: cubrid.com, Good First Issue

Issue Types

Type name	Description
Correct Error	Issue that fixes bugs or errors.
Improve Function/Performance	Issue that improves existing features or performance.
Development Subject	Issue that adds new features.
Internal Management	Issue for internal management. Use when changes are not related to contributions. e.g. changing the version name within a program or code from 10.2.0 to 11.0.0.0
Refactoring	Issue that changes unnecessary code clean-up, code structure, and repository separation.
Task	The issue type is applied if there is no category corresponding to the above issue type but is not recommended. (Example of use: release)
Sub-task	This issue type is applied when an issue is a small unit created inside the issue.

Component

CBRD

Category Component
QP SM DS Utility

Module Component
Build CI Coding Style Community Document
Broker/CAS Server Communication CSQL
Query Parser Query Semantic Check Query Rewriter Query Optimizer XASL Generator Query Executor Scan Manager Schema Manager Java SP
Backup/Restore Buffer pool Catalog Disk/File DWB FBO Heap Index Locator Lock Log/Recovery MVCC TDE Transaction Vacuum
Failover HA Heartbeat Logcopier Logapplier Replication

APIS

Module Component
ADO.NET CCI GO JDBC Node.js ODBC OLEDB PDO Perl PHP Python Ruby

TOOLS

Module Component
CM Server CUBRID Manager CUBRID Migration Toolkit CUBRID Monitoring Query Browser Tools development

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.

Issue Content Template

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.

Correct Error

Description Test Build Repro Expected Result Actual Result Additional Information

• 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-b53ae4a Affected 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.

Example) CBRD-23903​

Improve Function/Performance, Development Subject, Refactoring

Description Specification Changes Implementation Acceptance Criteria Definition of done

• 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.

Example) CBRD-23894

Task, internal management

Description

• Description: Write down the purpose and description of the work.