各位社区开发者好， 同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 范佳臣