From dca11d4c46738b278acd970b0876f701bd8ed55d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E6=A9=98=E6=82=A6?= Date: Tue, 13 Jun 2023 17:12:03 +0800 Subject: [PATCH] optimization of package introduction and management principles --- ...-introduction-and-management-principles.md | 79 +++++++++++-------- 1 file changed, 48 insertions(+), 31 deletions(-) diff --git a/articles/304-package-introduction-and-management-principles.md b/articles/304-package-introduction-and-management-principles.md index 22d841e..6881fdc 100644 --- a/articles/304-package-introduction-and-management-principles.md +++ b/articles/304-package-introduction-and-management-principles.md @@ -37,6 +37,7 @@ 龙蜥社区使用 Gitee 管理 Anolis OS 发行版及所有 SIG 组的软件包代码,统一放在 [https://gitee.com/openanolis]() 组织下。 + ### 2.1 软件包在代码仓库的位置 此处展示使用较为频繁的几个软件包仓库的信息: @@ -61,27 +62,36 @@ | | + + + ## 3. 软件包引入 -### 3.1 软件包引入原则 +### 3.1 软件包引入基本原则 软件包引入申请人主体可以是产品发布 SIG 组成员,也可以是其他 SIG 组对应软件包的 owner(以下统一称为「软件包负责人」)。当软件包引入前,软件包负责人需明确软件包引入原则,不符合软件包引入原则的组件,不允许引入。 **程度** | **要求项** | **补充说明** --|--|-- -must | 软件包的内容必须遵守国家法律法规、遵守社会公序良俗 | +must | 软件包的内容必须遵守国家法律法规、遵守社会公序良俗 | must | 软件包不允许存在合规、安全问题 | 例如:无 license 或 license 尚存在争议的软件 must | 软件包能给出明确的 License,并且属于开源软件的白名单范围内 | [license 白名单](https://gitee.com/anolis/anolis-ci-test/blob/master/utils/license_check/white_black.xlsx) -must | 软件包在引入时,应该说明背景和用途 | +must | 软件包在引入时,应该说明背景和用途 | must | 软件包在龙蜥社区的 rpm tree 中从未引入过,且软件命名规范,遵循上游社区命名方式 | 同一款软件只能存在 rpm tree 的其中一个仓,如有,后加的仓库应当合并到先有的仓库。例如:src-anolis-os 和 src-anolis-sig 不可以包含同名软件包 -must | source.tag.gz 从上游开源社区下载正式发布版本 | md5 值和上游相同 | -must | 原则不允许引入其他二进制,所有的构建依赖和运行依赖都要满足已经存在 OS 的发行版内 | 针对孵化期内的软件,支持额外讨论决策 -must | 需要从源码构建,生成对应的 rpm | 如果对构建依赖版本多要求的(比如:依赖多个 kernel-devel 版本),则需要构建多次 -must | 软件包对应的上游开源社区仍在运营,并在持续发布 release | 运营是指有代码提交、代码和入、issue解决等,代表上游社区的代码仓并没有被废弃 -must | 软件包所需要的全部运行依赖必须已经存在,如果不存在,则必须按照同等规则先引入 | +must | 软件包对应的上游开源社区仍在运营,并在持续发布 release | 运营是指有代码提交、代码和入、issue解决等,代表上游社区的代码仓并没有被废弃 +must | 新引入软件需要遵循 follow upstream 模式,即 source.tag.gz 是来自上游开源社区的正式版本 | md5 值和上游相同,且选取版本为正式 release 版本 +must | 原则不允许引入其他二进制,需要从源码构建,生成对应的 rpm | 如果对构建依赖版本多要求的(比如:依赖多个 kernel-devel 版本),则需要构建多次 + must | 软件包所需要的全部构建依赖和运行依赖必须已经存在,如果不存在,则必须按照同等规则先引入;如果已经存在,但是需要更新版本,则需要有完整评估,不能影响其他组件。 | 核心包和成熟包必须将构建依赖和安装依赖全部引入;
对于孵化期软件引入时,要求可以酌情降低,允许通过其他方式引入构建依赖和安装依赖;
Anolis OS 8 中允许使用 epel 仓库作为孵化期软件的构建依赖和所有软件的安装依赖,Anolis OS 23 没有 epel 仓库,不允许使用
Anolis OS 8 中如果有 epel 包转自维护,需要和自维护软件同等策略维护
在引入软件如果需要引入较多软件,并且有责任人进行长期维护,可以支持新增 group 或者 repo 的方式统一处理 + must | Anolis OS 8 中允许使用 epel 仓库 | 发行版团队的同学会定期巡逻 epel ,将 epel 的包列表与 Anolis OS 8 里面自维护软件的基线列表进行对比,如果发现 epel 高于基线列表,会发起告警并需要对应软件包的负责人进行处理。 + must | 软件维护策略:谁引入谁负责,同时需要负责引入该软件过程中的构建依赖和安装依赖软件。 | 当前构建依赖和安装依赖的构建由发行版团队进行看护,待 abs 功能完善后,支持由 sig 的主要 maintainer 自行决定构建和发布策略,但需要同时对发行版负责 +must | 同一个背景下引入的软件应该全部放到一个仓库中,不允许跨仓库存放。 | +must | 新引入的软件不允许对原有软件产生影响。 |比如:不能提供相同的能力,导致 repo 出现错误 must | 软件包 owner 需要评估软件的运行平台,缺省默认全部支持,如果存在不支持的架构则需要额外声明 | 目前龙蜥社区支持列表为:x86_64、aarch64 和 loongarch64 +must | 软件引入时,优先引入 Anolis OS 23 版本,其次同步引入 Anolis OS 8 版本。 | 如果仅引入 Anolis 8,需要上 TC 会议说明背景和原因。 -### 3.2 版本选型原则 + +### 3.2 版本选型原则 + 龙蜥社区的软件选型主要围绕「分层分类」理论展开,根据软件包对操作系统发行版的重要程度,以及整体应用场景模块化程度,设立不同的选型原则。 - 优先级上参照「分层分类」理论中的分层思想,从层级优先级高的软件包开始重点制定和维护策略; @@ -106,19 +116,23 @@ must | 软件包 owner 需要评估软件的运行平台,缺省默认全部支 - Anolis OS 7 和 Anolis OS 8 中现存的软件包。 + ### 3.4 软件包引入流程 1. **引入条件审查**:软件包负责人需根据 「[3.1 软件包引入原则](#wpzHw)」 和 「[3.2 版本选型原则](#S6HMX)」所载明的规范要求,明确软件包的代码符合要求、版本选型符合规范,同时明确软件包的演进和维护路线。 1. **提交软件包引入申请**:软件包引入涉及发行版基线变更,基线数据是通过社区的软件包集成项目 ([ospkg-list](https://gitee.com/anolis/ospkg-list)) 管理的。每一个软件包都需要通过 Pull Request 提交引入意向申请。该申请将由产品发布 SIG maintainer 负责审阅,必要时报请技术委员会成员审阅,如通过后则完成软件包基线数据的变更。 1. 如果软件包在 ospkg-list 里不存在,则需要参照「[附录1.1 软件包引入申请模板](#XvmFu)」填写一个新的 `{package}.yaml`文件。申请通过后由产品发布 SIG maintainer 创建新的仓库和对应分支; 1. 如果软件包在 ospkg-list 里已经存在,则无需提交新的 `{package}.yaml`,在现有软件包数据中添加新的字段即可。申请通过后由产品发布 SIG maintainer在现有仓库创建新的分支。 +1. **本地验证**:在本地进行软件包的构建和安装验证,保证基本功能正常。 1. **提交软件包代码**:根据 「[305 SPEC 规范](../articles/305-module-and-checklist-of-spec.md)」制作符合要求的 rpm tree 代码,并提交 PR 到对应的软件包分支中。 1. **完成引入:** 产品发布 SIG maintainer,必要时社区技术委员会指派成员,根据 review 规范审核对应的 PR,如通过后则完成软件包整体引入。其他 review 结果包括:打回修改,拒绝等。如拒绝则需给出明确的理由。 + ## 4. 软件包构建 软件包构建从构建目的角度可以划分为两种:自验证构建和正式构建。 + ### 4.1 自验证构建 该过程为开发者自行在本地或模拟环境中对软件进行构建,以验证软件包本身的构建能力或产出测试包供后续测试。目前推荐的方式有两种: @@ -131,43 +145,47 @@ must | 软件包 owner 需要评估软件的运行平台,缺省默认全部支 布小组 maintainer 获取相关 token。 + ## 5. 软件包发布与变更 ### 5.1 软件包发布原则 软件包发布指的是将通过正式构建流程生成的二进制推送到镜像 YUM repo 中。发布时会根据 ospkg-list 工具中的软件包基线数据信息,推送到对应的 YUM repo 中。
软件包经过正式构建得到 RPM 产物后,并不能直接发布,需要经过 abs 系统集成的 CI 流程后,由产品发布 SIG maintainer 执行软件包签名,之后推送 YUM repo 并生成发布单(Errata)。 - -### 5.2 软件包成熟度变更原则 -软件包成熟度与 YUM 位置相关,基本原则如下: +### 5.2 软件成熟度划分和变更流程 + +OpenAnolis 龙蜥社区中将所有的软件划分成三个阶段:系统包、成熟包、孵化包。 + +| 阶段名称 | 阶段介绍 | 维护主体 | 变更流程 | 补充 | +| -------- | ------------------------------------------------------------ | ------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | +| 核心包 | Anolis OS 中 Lay0 - Lay2 对应的核心软件范围,不允许随意更改。 | 发行版团队和内核团队 | 需要 TC 会议进行评审,评审通过后,即可引入。 | | +| 成熟包 | Anolis OS 中 Lay3 - Lay4 对应的稳定应用软件范围,由维护主体决定更新策略,支持按需更新。 | 发行版团队和龙蜥社区 sig | ospkg-list 发起转正请求,并提供转正材料,通过转正评审即可引入。 | 转正材料:软件的维护责任心和维护计划、软件的特性列表、引入软件的必要性、软件的真实使用场景和客户、软件依赖范围是否变更、 CI 检测的结果、稳定性或 CVE 相关信息等。 | +| 孵化包 | 龙蜥社区 SIG 和 社区开发爱好者新引入的软件,由维护主体决定更新策略,支持快速迭代。 | 龙蜥社区 sig 和开发爱好者 | ospkg-list 发起软件引入申请并通过 | | -- Anolis OS 每个大版本初次选型,成熟度自动为「系统包」级别; -- Anolis OS 发布后各个时期的软件包选型,如无特殊说明,成熟度自动为「孵化包」级别。 +### 5.3 Anolis OS 软件包仓库结构 -如软件包符合下列条件,可以变更成熟度: +根据 「[3.1 软件包引入原则](#wpzHw)」 和 「[5.2 软件包引入原则](#wpzHw)」中的分层机制,OpenAnolis 龙蜥社区将所有软件按照如下 [YUM 仓库](https://mirrors.openanolis.cn/anolis/) 进行管理,分为三大类:系统包、成熟包、孵化包。其中,;成熟包是由;孵化包是。 -- 符合软件包孵化成熟标准的软件包,可以从孵化池中结束孵化,变更为「成熟包」级别,条件如下: - - 软件包维护责任人清晰,维护计划清晰; - - 软件包代码质量稳定,通过所有 CI 检测条件,通过功能性测试,稳定维护至少一个软件包迭代周期; -- 符合软件包系统包标准的软件包,可以变更为「系统包」级别,条件如下: - - 软件包维护责任人清晰,维护计划清晰; - - 软件包代码质量稳定,通过所有 CI 检测条件,通过功能性测试,稳定维护至少一个软件包迭代周期; - - 软件包是 Anolis OS 必不可少的基础 OS 组件,或者是社区重点应用生态场景(场景列表见「[附录 1.2 社区重点应用生态场景](#Xwfk2)」; -- 符合软件包删除原则的软件包,需从 YUM 仓库删除,状态变更为「退休」级别。 +| 仓库名称 | 阶段 | 仓库介绍 | 仓库分层信息 | 仓库维护 owner | ISO 包含 | 仓库默认状态 | Anolis OS 8 仓库范围 | Anolis OS 23 仓库范围 | +| ---------------- | ------ | ----------------------------------------- | -------------------------------------------- | -------------------------- | --------- | ----------------- | -------------------- | --------------------- | +| BaseOS | 核心包 | Anolis OS 的核心软件 | Lay 0 - Lay2 的全量软件部分 Lay 3 软件 | 发行版团队 | 是 | ✅ 预装
✅ 使能 | 有 | 有 | +| AppStream | 成熟包 | 稳定的开源应用库和应用软件 | Lay 3 软件 | 发行版团队 | 是 | ✅ 预装
✅ 使能 | 有 | 有 | +| PowerTools | 成熟包 | 使用广泛的应用类软件 | Lay 3 软件 | 发行版团队 | 否 | ✅ 预装
✅ 使能 | 有 | | +| Extras | 成熟包 | Anolis OS release 组件 | Lay 3 软件 | 发行版团队 | 否 | ✅ 预装
✅ 使能 | 有 | | +| kernel-x | 成熟包 | 存放 x 版本的 kernel 包和该内核相关的组件 | Lay 3 软件 | kernel sig + 发行版团队 | 是 | ✅ 预装
❌ 使能 | 有 | 有 | +| Plus | 成熟包 | 通过社区 sig 运行较为成熟的软件 | Lay 3 软件 | 社区 sig | 是 | ✅ 预装
❌ 使能 | 有 | | +| DDE | 成熟包 | DDE sig 包含的桌面相关的软件 | Lay 4 软件 | 社区 sig | 否 | ✅ 预装
❌ 使能 | 有 | | +| HighAvailability | 成熟包 | 高性能 sig 包含的软件 | Lay 4 软件 | 社区 sig | 否 | ✅ 预装
❌ 使能 | 有 | | +| Epao | 孵化包 | 孵化阶段的软件 | | 社区 sig 和 社区开发爱好者 | 否 | ✅ 预装
❌ 使能 | 有 | 有 | -### 5.3 软件包发布流程 + +### 5.4 软件包发布流程 1. 经过正式构建得到候选发布(release candidate)包,abs 自动执行集成的 CI 流程,如未自动执行,则可在 abs 系统手工触发; 1. 通过所有 CI 测试项,或手工确认失败项无影响后,则达到发布条件。在 [Bugzilla 平台](https://bugzilla.openanolis.cn/enter_bug.cgi?classification=Anolis%20OS) 提交软件包发布需求,模板参考「[附录 1.3 软件包发布需求模板](#A5FyM)」;同时需填写发布单(Errata),如有多个软件包,则只需填写一个发布单即可,模板参考「附录 1.4 发布单模板」。 1. 产品发布 SIG maintainer 确认通过发布需求,分别执行软件包签名、推送 YUM repo、生成发布单操作,如软件包达到系统包级别,则还需额外更新镜像 comps 文件。 - -### 5.4 软件包成熟度变更流程 - -1. 在 ospkg-list 提交 PR,表明需要修改的目标成熟度,并在 commit 或 PR 描述中陈述软件包成熟度变更的必要性; -1. 产品发布 SIG maintainer 审核通过后,如涉及到仓库位置改动,需由产品发布 SIG maintainer 执行仓库位置改动操作。 - ## 6. 软件包删除 当某些开源软件不再符合 OpenAnolis 的规范时,需要将其从社区中删除。目前已知条件如下,持续更新: @@ -214,4 +232,3 @@ branches: ### 附录 1.4 发布单模板 > - -- Gitee