本文档为了对社区内的软件进行规范管理，包含软件引入、维护以及软件移除。
本文件定义软件应遵守的策略，所有提交的软件均需满足本文档技术要求。
软件包管理分为两个阶段：进入软件池、随版本发布。
| 进入软件池 | 随版本发布 | |
|---|---|---|
| 发布方式 | 仓库每日构建 | 仓库发布 |
| 对应分支 | master | release分支（如dev分支） |
| 质量标准 | 绝大多数功能可用 | 解决CVE、重大Bug，经过充分测试 |
维持一个master主干版本进行日常开发，在进入开发冻结期后（或发布版本后），拉出对应版本分支进行后期的维护。
当前已经存在master和dev两个主要分支，后续软件的维护存在多分支，多版本的情况。
如未特殊说明，本文都是针对master主干开发分支。
一个软件的引入指的是一个软件(项目)申请被引入到社区某一个项目中，依照本文描述的规则讨论，进而满足规则要求，最终在社区中建立相应repo的过程。
软件引入过程为软件申请引入审核通过后在代码托管平台创建软件代码仓库。
整个引入的过程都必须可被追踪。
为实现对软件生命周期的维护和管理。所有软件包被引入的每一步都需要有记录，这些记录被作为可信过程的存证。
同时也要遵循目前存在的三个仓库组件来进行软件包引入区分规则。分别是main(核心组件)、community(社区组件)、commercial(商业组件)。
main(核心组件)
内容说明：
1、该仓库包含了系统核心组件以及常用软件包。
2、仓库所有的软件质量得到系统官方保证。
3、仓库所有软件包只需依赖main组件即可完成编译、构建和安装使用。
准入条件：
1、优先选择中立上游已有的，满足技术需求的软件；
2、在项目只使用main组件仓库完成编译构建安装测试后提交集成申请，由集成管理员审核通过后才可以进入；
3、开源项目则需要从安全性上，满足以下条件：
a) 有至少3名社区贡献者，且活跃历史大小不低于3年;
b) 不允许引入存在可信问题的软件;
c) 仅允许从官方上游引入软件代码在相关代码托管平台初始化代码仓库。
4、从活跃度上，满足以下条件中的一条：
a) 在最近12个月内，有2个提交数，且issue回复率不低于30%;
b) 项目所属公司/社区对其有进行中的开发/维护计划;
5、在技术契合度上，按如下原则：
a) 技术方案不与现有技术方案冲突;
b)尽量选择提供单一技术的第三方库，避免引入大量冗余;
6、软件协议需遵循如下原则：
a) 必须兼容相关开源协议且不存在专利风险;
community(社区组件)
内容说明：
1、该仓库是对main组件仓库的补充，为社区提供尽可能丰富的软件包，提供这类软件包供社区爱好者使用，同时明确无法为该类软件包提供bugfix和CVE安全漏洞修复。
2、 受到软件包质量、技术成熟度、社区参与者投入等原因暂时无法完全满足系统的软件包发布的质量要求。
3、 仓库所有软件包无法独立编译、构建和安装使用，需要跟main组件一起使用。
准入条件：
1、 优先选择中立上游已有的，满足技术需求的软件;
2、 由社区爱好者通过在deepin-community/Repository-Manager上面提交PR，在PR审核通过后，在github建仓库。然后上传软件包代码，触发编译构建和安装以及检测，没有问题后自动导入。
3、开源项目则需要从安全性上，满足以下条件：
a) 有至少3名社区贡献者，且活跃历史大小不低于2年;
b) 不允许引入存在可信问题的软件;
4、从活跃度上，满足以下条件中的一条：
a) 在最近12个月内，有1个提交数，且issue回复率不低于30%;
b) 项目所属公司/社区对其有进行中的开发/维护计划;
5、在技术契合度上，按如下原则：
a) 技术方案不与现有技术方案冲突;
6、软件协议需遵循如下原则：
a) 必须兼容相关开源协议且不存在专利风险;
commercial(商业组件)
内容说明：
1、 该仓库是对main组件仓库的补充，为社区提供尽可能丰富的软件包。
2、 仓库软件包不是由官方编译构建，软件包兼容系统，并且不破坏仓库中各版本软件包原有的兼容性和依赖关系。受到软件包质量、技术成熟度、社区参与者投入等原因暂时无法完全满足系统的软件包发布的质量要求。
3、 仓库所有软件包无法编译、构建。软件包安装使用，需要跟main、community组件一起使用。
准入条件：
1、优先选择中立上游已有的，满足技术需求的软件;
2、 社区爱好者通过在github/linuxdeepin上面社区软件上面提交PR，在PR审核通过后，在github建仓库，然后上传软件包，触发安装以及检测，没有问题后自动导入。
3、开源项目则需要从安全性上，满足以下条件：
a) 有至少3名社区贡献者，且活跃历史大小不低于2年;
b) 不允许引入存在可信问题的软件;
c) 仅允许从官方上游引入软件代码在相关代码托管平台初始化代码仓库。
4、从活跃度上，满足以下条件中的一条：
a) 在最近12个月内，有2个提交数，且issue回复率不低于30%;
b) 项目所属公司/社区对其有进行中的开发/维护计划;
5、在技术契合度上，按如下原则：
a) 技术方案不与现有技术方案冲突;
b) 尽量选择提供单一技术的第三方库，避免引入大量冗余;
6、软件协议需遵循如下原则：
a) 必须兼容相关开源协议且不存在专利风险;
在项目开发过程中为满足产品新功能需求，自主研发一款软件用于满足相关产品需求而需要引入时，需要提供项目立项材料，提交审核组进行审核通过后方可入库。
自研软件引入申请必须包含以下信息:
在软件开发过程中为满足产品新功能需求，在经过技术调研后，发现已有成熟的开源软件项目可以使用，但当前仓库还没有入库。需要经过软件选型之后才能引入。
软件选型要注意项目来源、安全性、协议及法律风险、多架构支持、项目维护周期等等，输出可视化的软件选型报告。引入软件包按照谁申请引入那么就由申请人所在的研发团队进行维护，如果上游还在积极维护，有问题可向上游反馈；如果上游维护周期终止了，需要对该软件进行替换或接手维护。
开源软件引入申请必须包含以下信息:
功能描述：描述项目功能。
入库原因：描述选取该项目的原因。
项目来源：描述项目上游官方源码下载地址。
项目协议：描述项目的开源许可证。
项目版本：描述项目版本选取，该版本发布时间和预期维护周期。
开源软件引入原则:
软件包形式：软件应该是源码包，原则上二进制不应该被引入，应从源码构建。如果需要引入二进制，经由审核组讨论后决定。
正常构建：原则上，该软件应该在社区上可以被正确构建。当软件有尚未被引入的依赖关系，或者软件的运行或者构建依赖一个绝不可能引入社区的组件，此等例外，经由审核组讨论后决定。
案例性：每一个软件的引入决定，都作为案例，作为后续类似软件引入决策的参考。审核组对软件引入原则的一致性负责。
黑名单机制：存在于黑名单的软件不能引入。
审核组讨论后，可以将被拒绝引入的软件被记录到一个软件黑名单，作为记录，从而减少重复劳动。
| 维度 | 评估项 | 禁止引入/配套标准 | 优选引入/配套标准 | 退出配套 |
|---|---|---|---|---|
| 合法合规 | 1、获取来源可靠 2、许可证、知识产权符合社区要求 |
1、无明确来源（软件版本、补丁、漏洞） 2、无许可证、许可证要求无法履行 |
1、官方不再维护，或社区已经撤离的，考虑在本社区继续维护，不具备自维护能力的逐步退出 2、许可证，知识产权发生转移且存在合法合规风险，需逐步退出 |
制定本原则的目的是为了提升社区开源软件选型评估的质量。
软件引入选型
为了确保开源及第三方软件的质量，从社区引入某开源软件/版本，或者从第三方供应商处引入某第三方软件/版本，需要进行选型评估。
软件升级选型
在版本迭代和问题解决过程中，需要通过升级来引入新特性或解决功能、安全问题。在升级过程中，需要进行选型评估。
上游有做维护且发布不同的Release版本时，遵循
无上游维护时，则优先选择稳定分支中发布的tag；
不同软件对应不同维护力度，软件维护策略分为一般、重要、核心。具体定义如下：
| 子项\分级 | 一般 | 重要 | 核心 |
|---|---|---|---|
| 升级频率 | 3个月1次 | 半年一次 | 1年一次 |
| CVE问题 | 1月内解决 | 2周内解决 | 1周内解决 |
| 审查补丁 | 2个月内集中审查 | 1个月内集中审查 | 按周或及时审查 |
| 阅读代码 | 不要求 | 基本了解 | 熟悉 |
| Bug修复 | 1级：3月内解决 2级：6月内解决 3级：一年内解决 4级：不设截至期限 |
1级：2月内解决 2级：4月内解决 3级：6月内解决 4级：不设截至期限 |
1级：1月内解决 2级：2月内解决 3级：3月内解决 4级：不设截至期限 |
软件移除包含代码托管平台代码移除和软件包deb仓库软件移除。移除流程在社区发起和流转。
软件因开发场景需求如软件生命周期结束或其他原因需发起移除动作需遵守以下原则：
提供软件移除原因说明;
提供软件移除后兼容性保障说明;
提供软件移除相关依赖处理说明;
软件移除后，将该软件加入维护软件黑名单列表，后期默认禁止引入，如需重新引入需邮件发起申请。
另外，当满足以下两个条件时，软件包的退出申请可以被立即执行，对应repo将从项目中直接删除。
软件的License变化，或者其他法律法规影响了目前正在使用的版本，导致社区因为法务风险，不能继续集成该软件。
存在恶意代码或严重安全隐患且社区无能力修复的，要求软件被立即移除。
除以上原则外，剩下的条件对软件包的移除实行过程化管理：
随着技术演进与发展，软件因技术陈旧或架构落后，不能满足现有的应用场景被其他更优秀的软件所取代。
社区已经集成的版本过于老旧，且软件新版本License 或其他法律法规限制导致社区不能升级新版本。
软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的。
软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，社区半年以上未响应的。
社区运营状态不明确，通过Issue 或者邮件等方式询问社区是否继续维护，社区半年以上未响应或者答复停止维护的。
如果软件符合以上任何一条退出条件，审核组与相应SIG的维护人员将首先分析该软件在当前社区中被依赖、被使用的情况。
如果在社区中存在依赖关系，且短时间内不能解除，我们建议 SIG 在 github(或其他主流代码托管平台，例如gitee，gitlab等) 上新建分支代码仓，并主动进行社区维护动作。
如果开源软件因为License或其他法律限制导致不能升级新版本，并且该软件被大规模使用，由对应SIG组继续维护老版本。
欢迎社区开发者和用户提出宝贵建议，以上规则将根据反馈意见以及社区实施情况不断完善。