贡献给 CentOS Stream

1. 帐户

要是你有兴趣贡献给 CentOS Stream，你必须拥有一个 CentOS FAS 帐户。

2. 访问库

当你完成帐户的设置后，你便可以在本地复制相关的库。现有的库收录于两个位置：

1. dist-git repositories

2. source-git repositories

利用 source-git 作出贡献已进入试用阶段，因此事情如果出乎意料之外，请保持友善 —— 我们乐意收到你的反馈并作出改善。要是你有不清楚之处，请直接与产品拥有者或通过 centos-devel@centos.org 与我们联络。

2.1. 分叉及复制

当你从网页界面找到库后，请将它分叉并进行复制。

dist-git:

$ git clone ssh://git@git.centos.org/forks/$user/rpms/rpm.git

source-git:

$ git clone ssh://git@git.stg.centos.org/forks/$user/source-git/rpm.git

请勿忘记为主库设置 upstream 远程库（不是上游计划）：

dist-git:

$ git remote add upstream ssh://git@git.centos.org/rpms/rpm.git

source-git:

$ git remote add upstream ssh://git@git.stg.centos.org/source-git/rpm.git

本地复制完成后，你应该切换到 c8s 分支。要是该分支不存在，请切换到 c8 —— 这意味著该组件没有 CentOS Stream 的改动，而是追随最新的 CentOS Linux 8 发行版本。

3. 创建改动

这是你能大展拳脚的地方！你可作出以下两类改动：

1. 修改源码

2. 修改组件（spec 档，额外源码如下游配置文件）

3.1. 提交 pull 请求

我们采用的是你或许熟识，源自上游库的标准 git 工作流程：

新增本地 git 分支
提交改动（若是你反向移植上游的改动，请尽可能保留上游的提交消息）
把分支推送到你的分叉
最后，利用 Pagure 网页创建一个 pull 请求

3.2. Dist-git 对比 Source-git

如果你熟识 CentOS 及 Fedora 是如何包装组件，你可能认识 dist-git：每个库代表一个源程序 RPM 组件，并包含所有 RPM 源码档（RPM spec 档，上游的 tarball 检验码，还有修正档及其它文件）。然而库本身并不包含源码 —— 你必须执行 %prep 步骤才会出现。

至于 source-git，我们解压源码档并加入上游的改动作为额外的改动。现时这些库未包含上游的 git 日志：我们只是解压上游发行版本的相关压缩档作为首个 commit。如欲更详细知道 source-git 库的运作方式，请移玉步到 packit 的文档。

你可选择你首选的方式作出贡献：dist-git 或 source-git 都同样可行。

3.3. 在 source-git 库提交改动

如果你想更新组件的文件（收录于 SPECS 目录内），请直接进行修改 —— 它们不用特别处理。

3.3.1. 通过在 spec 档内定义修正档来更改源码

在源码内置立改动就须要多一点功夫。更改 CentOS Stream 组件的方法是创建修正档并在 spec 档内定义修正档。组件在被创建时会于 %prep 阶段套用修正档。

要是你更新了源码，并知道 spec 内要添加修正档，请在 spec 档内加入你所选用的修正文件名称：

Patch123: my-special-change.patch

接著你必须在提交消息内为改动加入以下注脚

We need this change in CentOS Stream

patch_name: my-special-change.patch
present_in_specfile: true

Signed-off-by: Tomas Tomecek <ttomecek@redhat.com>
---
 src/code.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

当我们的自动化系统，packit，创建 SRPM 档时，它会读入该提交消息，明白该修正档已定义于 spec 档内，然后把所提交的改动建成一个修正档，文件名取自 "patch_name" 栏。

这是更改源码的首选做法，因为你能操控整个程序。

3.3.2. 修正源码：让 packit 处理修正档

要是 packit 在提交消息内找不到上述的附属数据：

它会在 spec 档内加入新的 patch 项目
然后从所提交的改动创建新的修正档

这是较方便，却容易出错。要是此方法行不通，请引用上述方法手动加入附属数据。

3.4. 在 dist-git 库提交改动

这里的情况亦很相似：你可直接更改组件的包装过程，这些文件收录于 SOURCES 及 SPECS 目录。

要你你想更改源码，程序上与 source-git 便大有分别：

改动必须以修正档的形式出现
该修正档必须放进 SOURCES 目录内
并且正确定义于 spec 档内（请确保它能干净利落地套用到源码上）

3.4.1. 创建 pull 请求后

当你为 source-git 库提交 pull 请求后，系统会自动抽出改动并创建它 —— 那些包含你的改动的 RPM 将会出现，好让你能测试它们，或者确定组件能成功创建。

一旦你的改动获接纳，它将会被标签为 accepted。我们的自动化系统将会创建相关的 bugzilla 并附上修正档，然后便有待 RHEL 的维护者接手，在内部进行提交及建设，好让它能纳入 CentOS Stream —— 这个程序需时，所以请耐心等候。

4. 取得审阅

若然要把你的改动纳入 RHEL 及 CentOS Stream，它必须获相关组件的 RHEL 维护者审阅及认可。我们会在背后确保他们能看见你的改动。要是你未获得反馈，请在 freenode 的 #centos-devel 频道求助。

5. Rebase

随著新的改动出现于 CentOS Stream，你或许需要 rebase 你的 pull 请求。

6. 它会获接纳还是被拒？

我们在此先说明，就算你的 PR 获接纳，它也永远不会被 merge 的。它必须先被纳入开发版的 RHEL 中，然后它才能归入 CentOS Stream。到那时，你便会成为该改动的贡献者。

Translation of revision 12