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