基于社区和 RM 例会收集到的意见，对质量分层 / 分级策略， L1/L2 的软件基线进行公示，持续至 6/10 （每个版本可持续刷新）
分层质量策略
分层
维护
发布目录
兼容性要求
测试
L1
1. 例行 按周 同步社区补丁 / 按牵引 SLA 进行修复 2. Committer 梳理代码关键流程，有自维护自演进能力 ; 回馈上游社区，建立开源影响力
BaseOS
软件包及软件包 API 、 ABI 在某个 LTS 版本的生命周期保持不变， 跨 LTS 版本不保证 。
1. 基于开源测试套开展测试 2. 补充专项 /DFX 测试
L2
1. 例行 按双周 同步社区补丁 2. 漏洞按牵引 SLA 进行修复
BaseOS
软件包及软件包 API 、 ABI 在某个 SP 版本的生命周期保持不变， 跨 SP 版本不保证 。
1. 基于开源测试套开展测试 2. 结合使用场景测试
L3
1. 例行按月同步社区 BUG 2. 漏洞按牵引 SLA 进行修复
BaseOS
不做兼容性保证
1. 基于开源测试套开展测试
L4
1. 例行按月同步社区高危漏洞 / 关键 bug
Everything
不做兼容性保证
1. 基于开源测试套开展测试
不涉及
1. 被动响应漏洞 /BUG 修复
EPOL
不做兼容性保证
1. 保障 RPM 维度功能可用
L1/L2 软件范围清单
包名
质量基线
包名
质量基线
包名
质量基线
包名
质量基线
1
acl
L1
qemu
L1
iproute
L2
libtirpc
L2
2
alsa-lib
L1
systemd
L1
iptables
L2
libvirt
L2
3
bzip2
L1
xz
L1
kmod
L2
libxcrypt
L2
4
curl
L1
zlib
L1
libXext
L2
libxslt
L2
5
dbus
L1
dbus-broker
L1
libXi
L2
libyaml
L2
6
e2fsprogs
L1
NetworkManager
L2
libXrender
L2
lvm2
L2
7
elfutils
L1
audit
L2
libXtst
L2
mesa
L2
8
gcc
L1
bash
L2
libaio
L2
ncurses
L2
9
glibc
L1
cairo
L2
libarchive
L2
ntp
L2
10
gnutls
L1
coreutils
L2
libcap
L2
openldap
L2
11
grep
L1
cronie
L2
libcap-ng
L2
popt
L2
12
iputils
L1
dconf
L2
libcgroup
L2
readline
L2
13
kernel
L1
ethtool
L2
libevent
L2
samba
L2
14
krb5
L1
expat
L2
libiscsi
L2
shadow
L2
15
libX11
L1
findutils
L2
libnet
L2
sqlite
L2
16
libxml2
L1
freetype
L2
libnl3
L2
sssd
L2
17
openssh
L1
glib2
L2
libpng
L2
which
L2
18
openssl
L1
gmp
L2
libselinux
L2
zstd
L2
19
pam
L1
gtk2
L2
libsolv
L2
util-linux
L2
20
python3
L1
gtk3
L2
libtiff
L2
oncn-bwm
L2
---------------------------------------------------------------------------- 各位社区开发者好，
同 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 范佳臣
-
Fanjiachen(Jiachen,openEuler)