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 范佳臣