#  需求开发和版本发布流程

openEuler社区是一个开放的社区。致力于打造统一和开放的Linux操作系统。社区每年都会定期发布社区创新版本，本文档主要的目的是——让您了解社区版本开发和发布的流程，同时指导您如何把对社区的需求交付到社区的发布版本中。

**本流程所面对的用户**是：参与社区开发和发布的开发者：如果您是SIG团队的核心成员（核心成员指SIG的Maintainer和Committer），了解这一过程，便于您更好的配合社区版本发布的工作。另外，本文所描述的流程对象，是针对已经进入openEuler社区发布版本目录的软件包所对应的团队，以及负责社区版本发布的公共团队（如测试团队、发布经理团队等）。



## 需求开发和版本发布流程图

*本流程图用[draw.io](https://draw.io)绘制而成，该格式的文档也同步保存在figure文件夹，可以通过该工具编辑*

![](figure\openEuler社区需求和版本发布流程.png)



## 需求交付和版本发布流程指引

###  社区需求收集和讨论

社区的需求收集是开放的，如果您对openEuler有新的需求或点子，可以在该需求对应的Repository的Issue列表内提交**需求类型的Issue**，如果您不知道该需求具体对应的软件包的Repository地址，您可以在[community-issue](https://gitee.com/openeuler/community-issue)上提交需求Issue。

如果您希望该Issue得到广泛关注和讨论，您可以：

- 尽量将需求Issue提交到对应软件包的Repository所在的Issue列表。
- 提供尽量详细的新需求应用场景和优势分析。并在Issue留言区@你希望关注该需求的人。
- **注意**：请在给新需求创建Issue的时候，选择“需求”类型的Issue，新创建的Issue状态会处于“新建”状态。此类Issue会获得开发团队、以及发布经理们的持续关注。
- 向[dev@openEuler.com](dev@openEuler.com)、[tc@openEuler.com](tc@openEuler.com)或者该需求对应的sig的邮箱列表发起讨论，召集更广泛的讨论。请注意，只要该需求的Issue没有关闭，在需求的任意阶段，都可以进行讨论。



**关于需求颗粒度的特别说明**

1、如果需求需要多个SIG参与，跨SIG交付的需求为了协同设计和开发，默认工作量最大的SIG组为该需求的Leader，如果不明确或有争议，需求提出方可以提交到TC讨论裁决。

2、此类需求的Leader需要尽量把该需求通过创建子任务的方式（如何分解子任务，请参考：[Issue使用指南](https://gitee.com/openeuler/community/blob/master/zh/contributors/issue-submit.md)，分解到每一个SIG团队，以便以跟踪。



**关于[community-issue](https://gitee.com/openeuler/community-issue)内的需求Issue特别说明**

在community-issue内的需求，经过开放讨论以后，如果该需求对应的软件包的Maintainer或Committer认可了该需求，需要讲该需求Issue转移到对应的Repository的Issue列表内，如何将Issue转移到自己的团队，请参考[Issue使用指南](https://gitee.com/openeuler/community/blob/master/zh/contributors/issue-submit.md)。



##  2、需求分析和排序

###  需求分析（可选）

如果您认为该需求的场景比较复杂，为便于大家对该需求的理解一致，可以对该Issue开展需求场景分析。该活动：

- 可以提出人讨论需求的具体使用场景，共同评估场景的完备性。还可以讨论该需求的优缺点、业界情况等，以方便其他开发者更好的理解该需求。
- 可以在需求Issue的描述框里补充完成，或者在评论区完成，也可以通过单独的附件进行说明。
- 如果该附件需要进入团队的Doc目录，为保证可追溯，在在提交PR的时候关联到对应的需求Issue。
- 如果您想更加广泛的向大家推荐分析成果，在得到组内一致认可后，您还可以推送到wiki或openEuler的博客上。

###  需求排序（可选）

如果团队内的新需求较多，您可以通过优先级标签，对需求进行排序。（请注意：只有团队内的核心成员和Issue创建人才能对优先级标签进行修改）

需求可以设置三类优先级标签，分别是：

- priority/high
- priority/medium
- priority/low

请注意，优先级排序是为了更好的吸引大家的关注，以及便于查找，并不标识为该需求是否纳入团队的开发计划。



##  3、确认版本的需求范围

###  讨论和确认需求上线计划（SIG团队内）

新需求的上线计划由SIG团队内的核心成员讨论后决定。

- openEuler社区版本的发布计划是固定的、以及可预期的。发布经理会在社区公告新版本的发布计划，同时在社区创建以发布版本名称作为社区的里程碑，比如openEuler 20.9。具体可以参考：[openEuler通用开发计划时间表](http://development-schedual.md)。社区所有的版本发布计划都遵循该时间表。如果需要了解具体的开发版本的计划，可以去发布经理的[版本发布计划文件夹]()

- 对团队的核心开发者们，要在团队内部就需求在社区的上线计划达成一致，并将新需求匹配到openEuler的社区发布版本计划，以便于社区内的所有开发者能够了解到该需求在openEuler操作系统的上线计划。
- **如何匹配到社区发布版本计划**：只需要将新需求Issue的里程碑选择到对应的社区版本，并查看社区版本发布计划，匹配对应的迭代计划（（为了便于高效的管理需求的上线计划，发布经理会把一个开发周期分为多个迭代））并打`MileStone/Interation N`（“N”代表对应的迭代数）标签。一个需求只要已经完成以上两个信息的填写，该需求的状态会由社区Bot直接调整到“已确认”。
- **如何处理未决需求**：
  - 如果需求的交付计划并不在预备启动的新版本交付，但会考虑其后继的版本，可以将该需求的里程碑选择到新版本的下一个，甚至下下个版本。
  - 如果需求是否交付有争议且不能在短时间内决定，请手工将该需求的状态调整成“已挂起”。

**注意**：新版本的**需求冻结日**，是新版本**启动日**的后一个月（新版本的需求收集启动是在上一版本拉分支日开始的）。所以如果需求要进入下一个社区版本。请在“需求冻结日”之前给新需求完成里程碑和迭代计划的匹配。

###  收集并发布社区新版本需求清单（发布经理）

社区新版本的需求清单由该版本的发布经理确认的。在上一个社区版本拉分支阶段，发布经理会启动下一个版本的需求收集工作。在此期间，发布经理会通过[dev@openuler.com](dev@openuler.com)以及[tc@openeuler.com](tc@openeuler.com)定期向社区同步需求收集的进展情况。



- 发布经理通过类型为“需求”的Issue，以及Issue的里程碑属性确认版本的需求清单。发布经理在新版本“启动日”会对新版本的需求经理进行整理
  - 如果需求Issue处于“新建”状态，但未给出具体的版本，发布经理会和该需求的SIG团队核心成员联系并确认，所以请在新版本“启动日”前，完成所有新需求的确认工作。
  - 如果需求Issue的里程碑在新版本交付，但未给出迭代计划，发布经理也会和核心成员联系。所以同样请在新版本“启动日”前，完成所有新版本的需求的迭代交付计划的确认工作。

- **注意**：由于版本的集成发布需要社区的多个公共组之间协调工作，所以版本设置了协调开发过程的各类冻结点、拉分支点和测试阶段，以及配套的质量控制策略。开发团队需要遵守这些策略，以便于需求和软件包可以顺利的集成到openEuler，并满足openEuler的发布要求。

发布经理完成新版本的需求整理以后，会根据社区版本集成发布的冻结策略，检查各开发团队提供的需求计划。如果计划和社区的发布计划不符，发布经理也会和核心成员联系确认。



**重要**：为了提高社区开发效率，减少不必要的沟通成本，SIG的核心成员应了解社区开发计划的里程碑、冻结点的要求。了解此类信息，请参考：[openEuler社区版本发布计划时间表](development-scheudal.md)、[openEuler社区版本开发里程碑和质量策略说明](update-policy.md)。如果对其中内容有疑问，可以向[dev@openeuler.com](dev@openeuler.com)、或者[community@openeuler.com](community@openeuler.com)发送求助邮件。

发布经理在对所有新需求进行确认以后，会把里程碑标记为即将启动的新版本的需求收集起来，通过正式的模板向社区所有公开的邮箱列表公告，并提交到技术委员会备案。最终完成新版本的需求清单发布的工作。

### 变更版本需求计划

在“需求冻结日”前的需求变更，由核心成员自行调整。在该日之后的计划变更，无论是交付版本调整，还是迭代计划调整，都需要SIG团队成员向发布经理通过邮件发送变更申请。



## 4、确认版本软件包清单

社区发布版本和发行光盘的软件包清单，由技术委员会下的包管理小组进行统一管理。

- 如果需要将新的软件包引入社区发布版本，需要向包管理委员会提交PR申请，更新社区的软件包列表。
- 如果软件包需要进入社区发行光盘（由于发行光盘的维护周期更长，需要保证生命周期内的团队有持续稳定维护的能力），需要向技术委员会申请。

以上两类申请都可以参考：[软件包加入社区发布版本SOP](https://gitee.com)

包管理小组在需求冻结日基线社区新版本的软件包清单。

如果新需求导致软件包依赖变更，团队的核心成员因充分识别变造成的影响，并和影响到的技术领域或团队充分的沟通和达成一致。如果有冲突或争议，应提交到TC委员会申请仲裁。



## 5、需求分解（可选）

如果该需求涉及的工作任务量大，或者需要分阶段交付，或者需要多人配合交付。这种情况下，可以通过创建子任务，把需求拆分成不同的工作任务。如何拆分需求，请参考：[Issue使用指南](https://gitee.com/openeuler/community/blob/master/zh/contributors/issue-submit.md)。



## 6、实现方案设计（可选）

如果需求的实现涉及较复杂的业务逻辑或算法等，可以对此进行方案设计。该活动：

- 可以在对应需求Issue的描述框里补充完成，或者在评论区完成，也可以通过单独的附件进行说明。
- 如果该设计是一个附件，且附件需要进入团队的Doc目录，为保证可追溯，在提交PR的时候关联到对应的需求Issue。
- 如果您想更加广泛的向大家推荐分析设计成果，您还可以推送到wiki或openEuler的博客上。



## 7、需求开发验证和软件包更新

### 需求开发

需求由贡献者在本地开发，并在本地完成相应的测试。各sig团队应向贡献者提供对应的本地测试框架和用例集。

### 需求代码提交

1、请在提交PR的时候，确保关联对应的需求Issue编号。请注意某些sig团队会要求在提交需求的同时，需要同步提交测试用例。

2、提交PR以后会自动触发**门禁测试**，门禁测试的内容由Maintainer维护，如何查看门禁测试结果请参考[PR提交指南](https://gitee.com/openeuler/community/blob/master/zh/contributors/pull-requests.md)。

3、所有人都可以检视该PR。提交人应公平公正的对待每一个检视意见，并及时回应。

4、门禁测试通过后，团队核心成员才可以批准PR。审核PR请参考：[PR提交指南](https://gitee.com/openeuler/community/blob/master/zh/contributors/pull-requests.md)。

5、批准PR后，如果没有冲突，系统会自动合并到Master分支上

6、对各开发团队来说，可以在社区的OBS上创建本项目的OBS工程，定期（比如每日）完成对新增代码的RPM打包构建以及相关的软件包测试。请参考：[如何生成OBS包](http://create-obs-package.md)

7、开发团队在需求Issue上承诺的时间点之前，把承载了新需求的软件包更新到社区的`OBS  mainline`工程上，并附上相关信息，具体请参考：Maintainer工作指南



## 8、社区发布主干每日构建和测试

1、**每日构建**：社区在OBS上的`mainline`工程监测到软件包有更新，会启动每日构建测试。请注意，openEuler的每日构建工程只**保证新软件包不会对基本功能造成破坏**：详细了解每日构建，请参考[社区开发分支使用指南](dev-branch.md)。

2、**冻结期**：主干版本在版本正式启动后10周会进入冻结期。一个版本的冻结期大致有6周。具体的冻结计划可以参考版本的计划表。在冻结期间，Maintainer需遵守冻结质量策略要求，具体指导请参考[版本更新策略](update-policy.md)的相关章节。

3、**拉分支**：需求冻结后2周，发布经理会启动从主干拉发布分支的活动。从拉分支之日起，mainline上结束冻结，Maintainer可以推送新版本。

4、**β和发布测试**：测试团队会在新分支版本上完成β测试和发布测试，具体的测试策略和测试计划，请参考：[QA团队测试计划](https://gitee.com)



## 9、问题解决

从PR合入那一刻起，需求就有可能存在bug，bug被发现并通过Issue跟踪解决，具体的Issue处理流程请参考：[Issuce处理流程](https://gitee.com/openeuler/community/blob/master/zh/contributors/issue-submit.md)。开发团队需要持续关注和快速解决严重的bug。

- 每日构建发现的问题是需要优先得到解决的，这类问题会打上`bug-kind/daily-compose`标签，并被推送给对应的Repository。如果该问题阻塞了构建，测试团队会打上`bug-kind/blocking`标签。
- 一旦社区发行版本分支被拉出，测试团队会对发行版本展开大量的测试，在这个过程中可能会陆续发现需求的bug，并推送到该需求所属的Repository。此类问题会被打上`bug-kind/Release`标签。如果该问题对测试活动造成了阻塞，sig-QA团队还会给它打上`bug-kind/blocking`标签。**如果两个标签同时出现，说明该问题已经严重影响到发行版本的测试活动，需要团队尽快确认和解决**。
- 在社区发行版本的分支被拉出以前，bug的修改在master上完成以后推送软件包到mainline分支。在分支拉出以后，bug的修改应该backport到软件包的分支版本。这样做，是为了满足并行开发的，以及发布分支隔离冗余需求的需要。具体请参见：[Maintainer工作指南]()



## 10、确认文档清单和完成文档开发

文档开发团队负责确认社区版本的发布文档清单，并进行文档开发活动。

1、文档开发团队会根据需求和需求开发团队的核心成员确认配套文档的刷新范围和内容，并在需求开发团队内提交对应的任务类Issue。

2、需求开发团队在需求开发过程中，完成文档内容的写作，并向发布文档Repository提交对应的PR。

3、文档开发团队审核通过后，完成对应内容的文档开发和翻译工作。

4、文档开发团队可以向QA团队提交文档测试日申请。版本发布前，发布经理会确认配套文档的发布状态。发布评审会议，文档开发团队需派代表参与。

5、文档开发完成以后，配合版本发布完成配套更新。



## 11、版本发布质量评估

社区版本的是否发布由发布评审会议决定，发布评审会议由发布经理组织召开，由技术委员会、社区营销代表、测试团队、安全委员会等派代表参与评审，

- 发布版本完成β和发布测试以后，测试团队向发布经理提供版本的测试报告，给出测试对质量的评估结果。

- 发布经理根据版本发布评估checklist，检查其他评估项的达成情况，评估版本发布的风险，并把结果提交给发布评审会议评审。

  

## 12、发布评审会议

发布评审会议根据发布经理提供的信息给出版本是否可以发布的结论。并以表决的方式投票判定（“多数通过”规则）GO或NO-GO的结论，具体请参考：[发布评审会议SOP](Go-NOGO-Meeting.md)