Bug Management ​

Response to Bugs ​

The Release and QA SIGs are jointly responsible for the quality of openEuler releases. The openEuler QA SIG controls the software quality of the community by formulating bug management policies and working with test teams to carry out tests on openEuler releases. The Release SIG manages releases by coordinating the openEuler community, developers, and test teams to ensure high-quality delivery of milestones of the development version and iterations of the maintenance versions. openEuler welcomes and encourages community developers to find or fix CVEs to continuously improve software user experience. The community will quickly respond to, analyze, and fix reported bugs based on feedback and build releases in a timely manner.

Supported Releases ​

The bug response process is designed for LTS versions and of the openEuler community and their services packs.

Bug Fixing Process ​

Version bugs are specific types of issues reported by community developers, test teams, or users. They are associated with version milestones. After an issue is submitted to the openEuler community, the maintainers or committers of the corresponding SIG are responsible for analyzing and handling the issue. The QA and Release SIGs periodically review version bugs in the community and promote the community to handle issues as soon as possible based on priorities. The following figure shows the end-to-end bug fixing process of the community.

Bug Reporting ​

Reporting Method ​

The openEuler community relies on Gitee issues for bug management. To improve version bug awareness efficiency, the openEuler community provides a dedicated issue feedback template that interconnects with the community awareness tool. Developers are advised to use this template to submit issues to the src-openEuler software package repositories so that SIGs can detect and handle the issues as soon as possible. The template is as follows:

**[Issue Title]: Briefly describe the issue, including the scenario, actions taken, and results. (Positive words are recommended.)**

**I. Bug Information**

**Kernel: **

**Component to which the bug belongs: **

**Version to which the bug belongs: **

**Bug description: **

**[Environment information]**
Hardware:
- Provide information about the faulty hardware in bare metal scenarios.
- Provide XML files or configurations in VM scenarios.
Software:
- Provide the OS version and branch.
- Provide the kernel information.
- Provide the version of the faulty component.
Network:
- If special networking is used, provide the network topology.

**[Issue reproduction]**: Describe operation details.
**[Actual result]**: Describe the result of the issue.
**[Additional information]**
Such as system message logs, component logs, dump information, and images.

**Reference link to bug details: **

**Link to the bug analysis guide: **
https:xxx


**II. Bug Analysis Feedback**
**Impact analysis: **

**Bug severity: (Critical/High/Moderate/Low)**

**Affected version check (affected/unaffected): **
openEuler-xxxx-xxxx: affected/unaffected

**ABI change (affected/unaffected): **
openEuler-xxxx-xxxx: affected/unaffected

Description of Bug Reporting Fields (Specified by the Issue Submitter) ​

Description of Bug Analysis Fields (Specified by SIG Maintainers) ​

Bug Severity Evaluation ​

The bug severity evaluation principles are developed by the QA SIG of the openEuler community. If you have any questions, contact maintainers of the SIG.

Contact ​

QA SIG ​

Release SIG ​