希望能后收集到大家的社区软件质量分级的建议，非常感谢 ~

---------------------------------------------------------------------------- 各位社区开发者好，

同 20230512 社区 RM 例会讨论，结合社区已有的发布目录分级、兼容性等级考虑定义 openEuler 质量分级，非常希望各位开发者 / 专家 提出您宝贵的意见 。

质量分级基线清单 见附件 ~ （新分级基线 见 D 列 F 列）

质量分级背景：

问题 1 ： 组件版本升级，导致 abi 变化 ，兼容性问题。例： mariadb 由 10.3.9-11.p01 升级到 10.3.34-1 时，模块 test_versioning.so 发生变化。

措施： 1. 宣传社区兼容性策略； 2. 提供社区兼容性分级变更流程，收集开发者意见并明确兼容性维护投入。

问题 2 ： 安全编译选项排查， EPOL 范围软件问题排查率低。例： 23.03 版本 bazel 、 greatsql 等 40+ 软件包 issue 未闭环。

措施： 1. 基于社区软件发布目录制定质量分级； 2. 匹配质量分级和测试活动，细化质量要求。

质量分级策略：

1. 分级规则：结合社区 软件发布目录分析、兼容性分析，统一制定质量分级。 Everything 范围内做质量分级， Epol 范围内不做质量分级。具体规则见表格

a) 质量分为 L1~L4 4 级。

b) 兼容性分级分为 L1 、 L2 、不涉及 3 级。

2. 分级基线：初版质量分级范围继承质量分级范围；后续兼容性分级伟座质量分级的补充；

a) 质量分级 L1 ：继承兼容性分级 L0 + L0.5 + L1 软件范围

b) 质量分级 L2 ：继承兼容性分级 L2 软件范围

c) 质量分级 L3 ：继承兼容性分级 L3 软件范围

d) 质量分级 L4 ： everything 镜像范围内，未做兼容性分级的软件范围

3. 维护投入：明确 L1 、 L2 软件包责任到 Committer ；基于版本审视质量和兼容性要求落地情况，对无法满足要求的软件包考虑 Commiter 替换或质量分级降级（同步进行发布目录的切换）。

4. 变更流程：随社区版本按季度发布的节奏，在版本选型、分支拉取阶段由各 SIG 决策，并在 RM-SIG 例会同步决策。原则上版本 beta 阶段后，不再对改版本的质量分级进行变更。

质量策略

分层

维护

测试

L1

1. 例行 按周 同步社区补丁 / 按牵引 SLA 进行修复 2. Committer 梳理代码关键流程，有自维护自演进能力 ; 回馈上游社区，建立开源影响力

1. 基于开源测试套开展测试 2. 补充专项 /DFX 测试

L2

1. 例行 按双周 同步社区补丁 / 按牵引 SLA 进行修复

1. 基于开源测试套开展测试 2. 结合使用场景测试

L3

1. 例行按月同步社区 CVE/BUG

1. 基于开源测试套开展测试

L4

1. 例行按月同步社区高危漏洞 / 关键 bug

1. 基于开源测试套开展测试

兼容性质量策略

分层

特征

举例

L1

软件包及软件包 API 、 ABI 在某个 LTS 版本的生命周期保持不变， 跨 LTS 版本不保证 。

kernel 、 glibc 、 openssh

L2

软件包及软件包 API 、 ABI 在某个 SP 版本的生命周期保持不变， 跨 SP 版本不保证 。

bash 、 audit

不涉及

版本升级兼容性不做保证。

BR 范佳臣