Release Manager的各位专家,
你们好;
兼容性策略不仅仅只有API或者ABI兼容的问题;
我们的下游客户,
要求兼容生命周期内, 性能兼容,
内存和CPU资源兼容;
简单的意思就是, 在兼容周期内,
性能是不能下降的, 各种硬件资源占有率不能上升;
openEuler社区质量分级策略规范,
并没有对相关问题做出明确定义;
From: Fanjiachen(Jiachen,openEuler) <fanjiachen3@huawei.com>
Sent: Sunday, May 28, 2023 11:14 AM
To: release@openeuler.org; qa@openeuler.org; oecompatibility@openeuler.org
Cc: dev@openeuler.org
Subject: [Dev] Re: [QA][基线公示]社区软件包质量分级策略-
基于社区和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
范佳臣
-
Zhoukang (A)