From 5509cda1419ebb881ef86d1c3d4e244524a19586 Mon Sep 17 00:00:00 2001 From: Shinwell_Hu Date: Sat, 18 Apr 2020 15:58:10 +0800 Subject: [PATCH 1/5] add zh/technical-committee/governance/software-management.md. --- .../governance/software-management.md | 118 ++++++++++++++++++ 1 file changed, 118 insertions(+) create mode 100644 zh/technical-committee/governance/software-management.md diff --git a/zh/technical-committee/governance/software-management.md b/zh/technical-committee/governance/software-management.md new file mode 100644 index 000000000..0f24ebd5c --- /dev/null +++ b/zh/technical-committee/governance/software-management.md @@ -0,0 +1,118 @@ +# openEuler 软件包管理策略原则 + +[TOC] + +## 关于本文档 + +### 目标 + + openEuler是一个致力于创建开放操作系统的合作组织。我们希望openEuler + +- 尽可能集成多的软件组件 + +- 鼓励所有人使用openEuler，并可以在openEuler上开发软件 + +- 使能任何人，在不违反license，进出口管制或其他相关法律的前提下，可以容易的制作安装介质 + +openEuler遵从 [Open Source Definition](https://opensource.org/docs/osd) ，满足这一定义的软件，被openEuler社区认同为开源软件。 + +提供适度，高质量的开源软件是openEuler主要目标之一。openEuler努力为其所提供的开源软件在生命周期内提供高质量的支持服务。开源软件自由众多，质量不一。本着提供高质量开源软件的宗旨，特别拟定本规则指南。本规则的中**必须**，**必须不能**，**应该**，**应该不能**的含义参考RFC2119。 + +### 范围 + + 本文档定义了openEuler软件包所需要遵从的策略要求。所以提交到openEuler的软件包需要满足本手册中定义的技术要求。 + +### 本文的改进和修订说明 + +- 本文档由openEuler技术委员会 （Technical Committee）主导起草和维护。本文档的最新版本总可以在 [这里](https://gitee.com/openeuler/community/tree/master/zh/technical-committee/governance/software-management.md) 找到。 +- 任何对于本文中涉及的规则的增加，修改，删除都**必须**被追踪，[请进入该追踪系统](https://gitee.com/openeuler/community/issues) 。** +- 最终规则的经过充分的讨论后，由技术委员会定稿。 + +## 软件包管理 + +openEuler的软件包管理分为两个阶段：**进入软件池**、**随版本发布** + +软件包首次引入到openEuler，进过一定的测试和评估，最终随openEuler版本发布，遵循的原则大体相同，不同的是随openEuler版本发布的软件是经过充分测试、没有合法合规问题和严重的缺陷。 + +| | 进入软件池 | 随版本发布 | +| -------- | -------------------- | ------------------------------------ | +| 发布方式 | **daily build** repo | **release** repo | +| 对应分支 | master | release 分支 (如openEuler-20.03-LTS) | +| 质量标准 | 绝大数功能可用 | 解决CVE、重大bug，经过充分测试 | + +### 分支管理 + +维护一个主干版本进行日常开发，在进入开发冻结期后（或发布版本后），拉出对应版本分支。 + +当前（2020年4月）已经存在**master**和**openEuler-20.03-LTS**两个主要分支，后续软件的维护存在多分支，多版本的情况。 + +如未特殊说明，本文都是针对**master主干**开发分支。 + +## 软件引入与引入原则 + +### 什么是软件引入 + + 一个软件的引入指的是一个软件(项目)申请被引入到src-openeuler项目中，依照本文件描述的规则讨论，进而满足规则要求，最终在src-openeuler中建立相应repo的过程。 + +整个引入的过程都**必须**可被追踪。目前 [https://gitee.com/openeuler/community/issues](https://gitee.com/openeuler/community/issues) 是这个过程的追踪系统。 + +**注意**：升级一个官方库中已存在的软件包不是软件选型，所以不在本规则的覆盖范围内。 + +Technical Committee通过对引入申请(Pull Request)的评审，管理软件引入。 + +### openEuler软件包引入原则 + +为实现对软件生命周期的维护和管理，基于证据的可信贯穿于选型的整个过程。在一个软件包被引入的每一步都需要有记录，这些记录被作为可信过程的存证。 + +* 软件**必须**有明确的来源。src-openeuler不作为任何软件的维护社区，因此引入到src-openeuler并进入openEuler版本的软件必须有清晰定义的上游社区。 +* 软件**应该**有明确的引入理由。 +* 软件**应该**是源码包，原则上二进制**不应该**被引入，应从源码构建。如果需要引入二进制，经由Technical Committ讨论后决定。 +* 原则上，该软件**应该**在openEuler上可以被正确构建。当软件有尚未被引入的依赖关系，或者软件的运行或者构建依赖一个绝不可能引入openEuler的组件，此等例外，经由Technical Committ讨论后决定。 +* 原则上，openEuler不引入**rootkit**或者其他类似存在可信问题的软件。 +* 存在于**黑名单**的软件**必须不能**引入。 +* 每一个软件的引入决定，都作为案例，作为后续类似软件引入决策的参考。Technical Committ对软件引入原则的一致性负责。 + +### 黑名单机制 + +Technical Committ讨论后，可以将被拒绝引入的软件被记录到一个软件黑名单，作为证据减少重复劳动。 + +https://gitee.com/openeuler/community/tree/master/zh/technical-committee/governance/blacklist-software.yaml + +### 必要的软件引入评估 + +| 维度 | 评估项 | 禁止引入/配套标准 | 优选引入/配套标准 | 退出配套 | +| -------- | ---------------------------------------- | :----------------------------------------------------------- | :---------------- | :----------------------------------------------------------- | +| 合法合规 | 1、获取来源可靠
2、许可证、知识产权 |  无明确来源（软件版本、补丁、漏洞）
 无许可证、许可证要求无法履行、有知识产权问题 | |  官方不再维护、或社区已经撤离的，考虑在openEuler继续维护，不具备自维护能力的逐步退出
 许可证、知识产权发生转移且存在合法合规风险，需逐步退出 | + +### 软件选型及引入前检查 + +| 检查点 | 说明 | +| ------------------------ | ------------------------------------------------------------ | +| 归一化 | 原则上一款软件只在src-openeuler中引入一次。 | +| 来源可靠 | 1、不能使用来源不明的，不能随意从网上拷贝一份代码使用，
| +| 规范化软件名称 | 1、 软件名称必须和官网/社区保持一致，不可随意命名，
2、 不允许以软件包中的子模块作为软件名，
3、 当软件是某个语言的开发库时，我们允许追加python-、perl-等前缀予以规范化管理。 | +| 版本年龄（官方发布时间） | 1、衰退期、EOS、EOM或者社区停运等不能引入
2、超过5年的大概率会禁选 | +| 官网必填 | 1、软件官方网址填写规范，使用软件供应商提供的网址，或者无单独正式官网的情况下，提供主流代码托管商上面对应的项目网址如github
2、不能使用maven、mvnrepository、springsource等托管库作为官方网址 | +| 软件包信息提供 | 1、必须提供官方提供的源代码包的下载地址，以达到可溯源
2、如果有需要二进制包，需要提供官方的二进制包下载地址 | +| license检查 | 1、待引入软件是否有license 对待引入软件的具有不友好的license需要特别关注：LGPL2.0，LGPL3.0，GPL2.0，GPL3.0，AGPL3.0等
2、入库时填写的license是否和官网保持一致，是否和软件包中license保持一致 待上载的源码包中是否包含license信息 高风险license的三方件需要提供源码和编译方法 | +| copyright检查 | 1、通过官网、社区、代码托管网站、源码包、发布件中等地方获取并提供copyright信息 | + +## 软件退出与退出原则 + +### 什么是软件退出 + + 一个软件的退出指的是一个软件(项目)申请从src-openeuler项目中删除，依照本文件描述的规则讨论，进而满足规则要求，最终在src-openeuler中移除相应repo的过程。 + +整个引入的过程都**必须**可被追踪。目前 [https://gitee.com/openeuler/community/issues](https://gitee.com/openeuler/community/issues) 是这个过程的追踪系统。 + +Technical Committee通过对引入申请(Pull Request)的评审，管理软件退出。 + +### openEuler软件包退出原则 + +当满足以下两个条件是，openEuler软件包的退出申请可以被立即执行 +1. 软件的License变化导致openEuler不能集成该软件 +2. 重大安全问题，要求软件被立即移除。 + +除了以上两个场景之外，openEuler对软件包的退出实行过程化管理。当一个软件申请从src-openeuler中删除时，这个软件首先被托管给sig-Legacy，不再由之前的SIG管理。sig-Legacy表示这个软件进入有限维护模式，这个sig不响应issue和安全漏洞警告。但是相应的软件构建还是正常执行，用户在理解风险的前提下，依然可以安装和使用这个软件。 + +Technical Committee例行审视sig-Legacy中的软件，制定每个软件的删除计划，并且在openeuler/community中公示。 \ No newline at end of file -- Gitee From ed15c9a805a18f7f0ceadfcb1b78d9793291b980 Mon Sep 17 00:00:00 2001 From: Shinwell_Hu Date: Sat, 18 Apr 2020 15:59:27 +0800 Subject: [PATCH 2/5] add zh/technical-committee/governance/blacklist-software.yaml. --- zh/technical-committee/governance/blacklist-software.yaml | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 zh/technical-committee/governance/blacklist-software.yaml diff --git a/zh/technical-committee/governance/blacklist-software.yaml b/zh/technical-committee/governance/blacklist-software.yaml new file mode 100644 index 000000000..3434183ee --- /dev/null +++ b/zh/technical-committee/governance/blacklist-software.yaml @@ -0,0 +1,2 @@ +blacklist-software: +- python2 -- Gitee From 4577a8c704479b4b7c69acc4ef61b9a6e09c9d68 Mon Sep 17 00:00:00 2001 From: Shinwell_Hu Date: Sat, 18 Apr 2020 16:10:38 +0800 Subject: [PATCH 3/5] update zh/sig-infrastructure/Repository.md. --- zh/sig-infrastructure/Repository.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/zh/sig-infrastructure/Repository.md b/zh/sig-infrastructure/Repository.md index 2e208489c..95a60af89 100644 --- a/zh/sig-infrastructure/Repository.md +++ b/zh/sig-infrastructure/Repository.md @@ -25,6 +25,7 @@ repositories: - name: abattis-cantarell-fonts description: "fonts repo" + upstream: "https://gitlab.gnome.org/GNOME/cantarell-fonts/" type: private ``` @@ -35,6 +36,7 @@ repositories: * `abattis-cantarell-fonts`: 你想创建的新仓库名字。 * `fonts repo`: 新仓库描述。 +* `"https://gitlab.gnome.org/GNOME/cantarell-fonts/"`: 仓库对应上游社区的 URL * `private`: 表示仓库的类型。 `private`意味着新仓库只对某些特定的人群可见。 @@ -58,6 +60,7 @@ community: repositories: - name: abattis-cantarell-fonts description: "fonts repo" + upstream: "https://gitlab.gnome.org/GNOME/cantarell-fonts/" type: private - name: accountsservice description: "account repo" @@ -109,6 +112,7 @@ community: repositories: - name: abattis-cantarell-fonts description: "fonts repo" + upstream: "https://gitlab.gnome.org/GNOME/cantarell-fonts/" type: private - name: accountsservice description: "account repo" -- Gitee From a34d28246c4859ca9cb948537b728665bc1113c8 Mon Sep 17 00:00:00 2001 From: Shinwell_Hu Date: Sat, 18 Apr 2020 17:01:23 +0800 Subject: [PATCH 4/5] update zh/technical-committee/governance/software-management.md. --- zh/technical-committee/governance/software-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/technical-committee/governance/software-management.md b/zh/technical-committee/governance/software-management.md index 0f24ebd5c..1c875f362 100644 --- a/zh/technical-committee/governance/software-management.md +++ b/zh/technical-committee/governance/software-management.md @@ -109,7 +109,7 @@ Technical Committee通过对引入申请(Pull Request)的评审，管理软件 ### openEuler软件包退出原则 -当满足以下两个条件是，openEuler软件包的退出申请可以被立即执行 +当满足以下两个条件是，openEuler软件包的退出申请可以被立即执行，对应repo将从项目中直接删除。 1. 软件的License变化导致openEuler不能集成该软件 2. 重大安全问题，要求软件被立即移除。 -- Gitee From e2f58a82bdab5e4160d4b1aa3f9aa215051b915b Mon Sep 17 00:00:00 2001 From: Shinwell_Hu Date: Sat, 18 Apr 2020 17:02:05 +0800 Subject: [PATCH 5/5] update zh/technical-committee/governance/software-management.md. --- zh/technical-committee/governance/software-management.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zh/technical-committee/governance/software-management.md b/zh/technical-committee/governance/software-management.md index 1c875f362..4feaa33b7 100644 --- a/zh/technical-committee/governance/software-management.md +++ b/zh/technical-committee/governance/software-management.md @@ -113,6 +113,6 @@ Technical Committee通过对引入申请(Pull Request)的评审，管理软件 1. 软件的License变化导致openEuler不能集成该软件 2. 重大安全问题，要求软件被立即移除。 -除了以上两个场景之外，openEuler对软件包的退出实行过程化管理。当一个软件申请从src-openeuler中删除时，这个软件首先被托管给sig-Legacy，不再由之前的SIG管理。sig-Legacy表示这个软件进入有限维护模式，这个sig不响应issue和安全漏洞警告。但是相应的软件构建还是正常执行，用户在理解风险的前提下，依然可以安装和使用这个软件。 +除了以上两个场景之外，openEuler对软件包的退出实行过程化管理。当一个软件申请从src-openeuler中删除时，这个软件首先被托管给sig-Recycle，不再由之前的SIG管理。sig-Recycle表示这个软件进入有限维护模式，这个sig不响应issue和安全漏洞警告。但是相应的软件构建还是正常执行，用户在理解风险的前提下，依然可以安装和使用这个软件。 -Technical Committee例行审视sig-Legacy中的软件，制定每个软件的删除计划，并且在openeuler/community中公示。 \ No newline at end of file +Technical Committee例行审视sig-Recycle中的软件，制定每个软件的删除计划，并且在openeuler/community中公示。 \ No newline at end of file -- Gitee