From 63ec59ecac3ab79b947ed09ef17add0b9abacf80 Mon Sep 17 00:00:00 2001 From: licihua Date: Thu, 15 Oct 2020 14:15:45 +0800 Subject: [PATCH] =?UTF-8?q?=E6=98=8E=E7=A1=AE=E4=B8=8A=E6=B8=B8=E5=81=9C?= =?UTF-8?q?=E6=AD=A2=E7=BB=B4=E6=8A=A4=E8=BD=AF=E4=BB=B6=E5=A4=84=E7=90=86?= =?UTF-8?q?=E7=AD=96=E7=95=A5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../governance/software-management.md | 66 ++++++++++++++----- 1 file changed, 51 insertions(+), 15 deletions(-) diff --git a/zh/technical-committee/governance/software-management.md b/zh/technical-committee/governance/software-management.md index f32dda52a..1039f2f03 100644 --- a/zh/technical-committee/governance/software-management.md +++ b/zh/technical-committee/governance/software-management.md @@ -6,7 +6,7 @@ openEuler是一个致力于创建开放操作系统的合作组织。我们希望openEuler -- 尽可能集成多的软件组件 +- 尽可能多的集成软件组件 - 鼓励所有人使用openEuler，并可以在openEuler上开发软件 @@ -82,16 +82,16 @@ Technical Committ讨论后，可以将被拒绝引入的软件被记录到一个 ### 软件选型及引入前检查 -| 检查点 | 说明 | -| ------------------------ | ------------------------------------------------------------ | -| 归一化 | 1、原则上一款软件只在src-openeuler中引入一次。 | -| 来源可靠 | 1、不能使用来源不明的，不能随意从网上拷贝一份代码使用，
| -| 规范化软件名称 | 1、 软件名称必须和官网/社区保持一致，不可随意命名，
2、 不允许以软件包中的子模块作为软件名，
3、 当软件是某个语言的开发库时，我们允许追加python-、perl-等前缀予以规范化管理。 | -| 版本年龄（官方发布时间） | 1、衰退期、EOS、EOM或者社区停运等不能引入
2、超过5年的大概率会禁选 | -| 官网必填 | 1、软件官方网址填写规范，使用软件供应商提供的网址，或者无单独正式官网的情况下，提供主流代码托管商上面对应的项目网址如github
2、不能使用maven、mvnrepository、springsource等托管库作为官方网址 | -| 软件包信息提供 | 1、必须提供官方提供的源代码包的下载地址，以达到可溯源
2、如果有需要二进制包，需要提供官方的二进制包下载地址 | -| license检查 | 1、待引入软件是否有license
2、入库时填写的license是否和官网保持一致；是否和软件包中license保持一致;高风险license的三方件需要提供源码和编译方法 | -| copyright检查 | 1、通过官网、社区、代码托管网站、源码包、发布件中等地方获取并提供copyright信息 | +| 检查点 | 说明 | +| ---------------- | ------------------------------------------------------------ | +| 归一化 | 1、原则上一款软件只在src-openeuler中引入一次。 | +| 来源可靠 | 1、开源软件都应该从开源软件官网获取或官网指定的代码托管地址获取。 | +| 规范化软件名称 | 1、 软件名称必须和官网/社区保持一致，不可随意命名，
2、 不允许以软件包中的子模块作为软件名，
3、 当软件是某个语言的开发库时，我们允许追加python-、perl-等前缀予以规范化管理。 | +| 社区运营状态检查 | 1、软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的，不建议引入，
2、软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，但是半年以上未响应的，不建议引入，
3、社区运营状态不明确，通过Issue 或者邮件等方式询问社区是否继续维护，半年以上未响应或者答复停止维护的，不建议引入。 | +| 官网必填 | 1、软件官方网址填写规范，使用软件供应商提供的网址，或者无单独正式官网的情况下，提供主流代码托管商上面对应的项目网址如github
2、不能使用maven、mvnrepository、springsource等托管库作为官方网址 | +| 软件包信息提供 | 1、必须提供官方提供的源代码包的下载地址，以达到可溯源
2、如果有需要二进制包，需要提供官方的二进制包下载地址 | +| license检查 | 1、待引入软件是否有license
2、入库时填写的license是否和官网保持一致；是否和软件包中license保持一致；高风险license的开源软件谨慎引入 | +| copyright检查 | 1、通过官网、社区、代码托管网站、源码包、发布件中等地方获取并提供copyright信息 | ### 软件包的批量引入 @@ -114,10 +114,45 @@ Technical Committee通过提交PR(Pull Request)来评审，管理软件退出。 ### openEuler软件包退出原则 当满足以下两个条件时，openEuler软件包的退出申请可以被立即执行，对应repo将从项目中直接删除。 -1. 软件的License变化导致openEuler不能集成该软件 -2. 重大安全问题，要求软件被立即移除。 +1. 软件的License变化，或者其他法律法规影响了目前正在使用的版本，导致openEuler因为法务风险，不能继续集成该软件 +2. 存在恶意代码或严重安全隐患且openEuler 社区无能力修复的，要求软件被立即移除。 -除了以上两个场景之外，openEuler对软件包的退出实行过程化管理。当一个软件申请从src-openeuler中删除时，这个软件首先被托管给[sig-Recycle](https://gitee.com/openeuler/community/tree/master/sig/sig-recycle)，不再由之前的SIG管理。sig-Recycle表示这个软件进入有限维护模式，这个sig不响应issue和安全漏洞警告。但是相应的软件构建还是正常执行，用户在理解风险的前提下，依然可以安装和使用这个软件。 +除以上描述两种场景外，剩下的场景openEuler对软件包的退出实行过程化管理： + +1. 随着技术演进与发展，软件因技术陈旧或架构落后，不能满足现有的应用场景被其他更优秀的软件所取代。 +2. openEuler 已经集成的版本过于老旧，且软件新版本License 或其他法律法规限制导致openEuler 不能升级新版本。 +3. 软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的。 +4. 软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，社区半年以上未响应的。 +5. 社区运营状态不明确，通过Issue 或者邮件等方式询问社区是否继续维护，社区半年以上未响应或者答复停止维护的。 + +如果软件符合以上任何一条退出条件，技术委员会与相应SIG的maintainer将首先分析该软件在当前 openEuler 社区中被依赖、被使用的情况。 + +1. 如果 openEuler 中存在依赖关系，且短时间内不能解除，我们建议 SIG 在 github(或其他主流代码托管平台，例如gitee，gitlab等) 上新建分支代码仓，并主动进行社区维护动作。 +2. 如果 openEuler 中不存在依赖关系，或者短时间内可以解除： + 1. 技术委员会将通知 release management 团队，将这个软件包从 openEuler 正式发行中移出，并在相应的release notes，以及spec文件中标识；软件包将移动到扩展软件包池中； + 2. 如果原 SIG 愿意继续管理这款软件，则需要承担修复 openEuler 社区例行巡检所发现问题的责任； + 3. 如果原 SIG 认为没有意愿继续管理这款软件，则相关软件包将从原 SIG 移交 sig-recycle + +### 开源软件自维护策略 + +开源软件符合退出条件，但是因上下游切换周期长，短时间不能退出的，由依赖方SIG或者本SIG 自建仓维护，具体原则如下： + +1. 知名社区或组织宣布停止维护、License 变化或出口管制原因导致不能集成新版本的，短期内由软件所在 SIG 建立的github(或其他主流代码托管平台，例如gitee，gitlab等) 项目维护，并且寻找替代软件，推动上下游尽快切换。 +2. 个人、小型社区或组织投入不足的，优先联系社区maintainer，传递openEuler 参与贡献的意愿，重新激活上游社区。maintainer 不响应的，需要将软件迁移到openEuler SIG 在github(或其他主流代码托管平台，例如gitee，gitlab等) 建立的项目下，由openEuler SIG维护。迁移后需要在原始上游社区发布openEuler SIG继续维护软件的通知，吸引社区其他参与者成为贡献者。 + +### 开源软件自维护质量要求 + +1. 运行在关键路径的软件（例如glibc、dpdk），或可能导致用户发生现网事故的（例如升级相关软件dnf）或暴露攻击面的软件（例如网络服务 vsftpd），需要熟悉软件实现原理与流程；明确软件应用规格；补充各维度测试用例，完成质量加固工作，对已经出现的问题举一反三，降低质量风险。 + +2. 运行在非关键路径，但是以后台服务方式运行或频繁调用的软件（systemd、sshd)，需要梳理软件应用场景、可以支持的规格、使用约束与限制等，结合软件使用场景梳理代码流程；结合使用场景补充测试、对已经出现的问题举一反三，降低质量风险。 + +3. 运行在非关键路径，且使用频率低，应用场景稳定的软件（例如anaconda，dconf），通过问题触发方式熟悉代码流程，开展各维度测试。 + +4. 不在用户现网环境运行或不影响用户现网运行的软件（如CUnit、Make、gdb），在openEuler 制品仓中维护，基于开源测试代码展开测试活动，定期从社区（如fedora、openSuse）同步补丁代码。 + +计划退出的软件需要继续按照维护策略维护一段周期，便于上下游切换，维护周期在openEuler LTS ReleaseNotes 中公布，在软件包的spec 文件中通过Provides: deprecated() 标识，明确退出时间的，增加时间选项（Provides: deprecated() == YYYYMMDD)。 + +如果到达了维护截止时间，满足退出条件，需要从原SIG 迁移到 [sig-Recycle](https://gitee.com/openeuler/community/tree/master/sig/sig-recycle) 下，由 sig-Recycle SIG管理，进入sig-Recycle表示这个软件进入有限维护模式，不响应issue和安全漏洞警告，但是相应的软件构建还是正常执行，通过EPEL 仓库对外发布，用户在理解风险的前提下，依然可以安装和使用这个软件。 Technical Committee例行审视sig-Recycle中的软件，制定每个软件的删除计划，并且在openeuler/community中公示。 @@ -141,7 +176,7 @@ Technical Committee例行审视sig-Recycle中的软件，制定每个软件的 openEuler社区版本分为长期支持版本和创新版本。[详见release SIG](https://gitee.com/openeuler/community/tree/master/zh/Release-Management)。 -- 长期支持版本（LTS）：**发布间隔周期定为2年，提供4年社区支持(暂定)**。社区首个LTS版本openEuler 20.03已于20年3月正式发布。 +- 长期支持版本（LTS）：**发布间隔周期定为2年，提供4年社区支持(暂定)**。社区首个LTS版本openEuler 20.03已于2020年3月正式发布。 - 社区创新版本（DEV）：每隔6个月openEuler会发布一个社区创新版本，提供6个月社区支持。 - 版本重新选型时，需由issue发起，相关软件升级的差异分析以统一的格式发布在issue的comments中。 @@ -207,3 +242,4 @@ LTS版本的软件升级后**不得影响兼容性列表**，兼容性列表由o | | | | | | SPEC文件 | 新增/变更/删除 编译依赖、安装依赖、依赖的软件版本变更 | | | | | 拆分软件包方式变更 | | | + -- Gitee