引言
openEuler 社区曾经建设起来了，也有不少合作伙伴, OSV, ISV 等参加进来。整个社区的治理构造也初步建设了起来。但毕竟是一个年老的社区，因而有一些流程方面还有待优化，很多文档还有待于欠缺。
鉴于有很多心愿参加到社区里的工程师对整个社区的运作流程，开发流程还比拟生疏，我总结了一个文档来帮忙一个工程师更容易的参加到社区中。
openEuler 社区概要
openEuler 的主站点是 https://openeuler.org/
主站点次要是提供一些入口，对于工程师来说，最重要的应该是 下载链接：
https://openeuler.org/zh/rele…
除了下载以外，对工程师来说，真正的 社区开始之旅的终点：
https://openeuler.org/zh/deve…
这个链接给大家做了一个简要的疏导，然而可怜的是，对于一个新人来说，信息量仍然十分大，可能有些摸不到头脑。上面，就让我带着大家一步步的化繁为简的做一次 openEuler 参加之旅吧。
法律合规是第一步，也是最重要的一步
“开源”这两个字眼尽管在很大水平上代表了自在，奔放，得心应手，合乎码农天生追“自在翱翔”的特质。然而开源并不是法外之地，因而法律合规是一个社区衰弱倒退最重要的前提，没有之一。因而，任何一个人，如果想要参加到 openEuler 我的项目中，第一步就是要 签订 CLA 协定。协定的签订网址是：
https://openeuler.org/en/cla….
尽管协定并不简单，然而作为一个码农，通常我都对这类法律文书都是免疫的，咱们连须要给本人赔钱的保险合同都不会多花上一分钟工夫看上一眼，对于这种须要本人贡献的条款又怎会关注呢？还有更要害的是，如果码农看懂了法律文书，那还是码农么？尽管这很大水平是咱们码农的现状，然而我还是倡议大家认真浏览一下协定，理解一下权利范畴并没有害处。
咱们是开源的
openEuler 社区原则上只承受开源协定的软件，哪些开源协定是社区认可的开源协定呢？大家能够参考上面的网址。这个网站上所列举的开源协定都是 openEuler 社区所能接收的协定。
https://opensource.org/licens…
对于社区自身，咱们默认应用 mulan V2 协定，https://opensource.org/licens…，这是一个十分敌对的开源协定，也欢送大家更多的应用这个协定来开发开源软件。
我能做点什么
在签订完 CLA 协定，理解咱们所认可的开源协定范畴当前，须要实现社区的注册。
因为 openEuler 自身是凋谢到 gitee.com 上，因而须要大家在 gitee 上领有账号。咱们也衷心希望 gitee 能成长为世界级的代码托管平台。
当大家实现了这些过程当前，就须要思考在社区里具体能做点什么了。参加社区有很多种办法和模式，如果总结起来，大体有上面的四类：
- 提交一些需要，或者 bug，简略来说就是察觉哪里用的不爽，间接提要求。或者在用 openEuler 的过程中发现了一些问题，而后须要在社区把这个问题提出来。
- 为社区修改 bug，这是更高一个层面的参加社区了，在这个层面，参与者本质上是以一个开发者的姿势进入到了社区中。个别咱们都提倡，除了提出问题，更期待大家能解决问题。
- 奉献软件包，发现 openEuler 缺失了一个软件包，帮 openEuler 把这个软件包补上。实际上奉献软件包的过程就是帮忙 openEuler 提供更丰盛性能的过程。心愿随着大家的参加，openEuler 可能成为一个“无所不有”的软件生态系统。
- 开发新软件，有本人的一些想法，独立开发一个全新的软件，并将这个软件奉献到 openEuler 社区，成为 openEuler 发行版本中的一份子。
咱们就一个个来看看这 4 种参加形式如何进行把。
网站和社区
在具体探讨这四类参加办法之前，我先给出三个网址链接。
- https://openeuler.org/
- https://gitee.com/openeuler/
- https://gitee.com/src-openeuler
第一个网址是 openEuler 的门户网站，是供大家获取一些通用信息的中央，后面曾经提到过了。而真正咱们所谓的“社区”则是体现在 2，3 这两个网址上。
这两个网址相互有链接，它们别离长这个样子：
长得这么像，为什么要分两个网址呢？两者有什么分工呢？咱们在后续解说中会缓缓的给大家说分明。
不管怎么样，这两个网址，以及外面的内容将会是社区工作的次要场合。尽管人机界面并不敌对，但我置信对于码农来说这不是一个大问题，因为码农们的世界素来都不已经敌对过。
参加形式一：提交需要 &bug
最根本参加社区的形式当然是要先用一用社区的物件，看看还有哪些须要改良的中央。提出一些有价值的倡议和意见了。这简直是最简略参加社区的形式了。
在社区中，咱们提交问题都是通过“issue”机制来进行。然而在提交之前，提交人得先明确这个 issue 要提交给谁。在社区里，咱们是一个个“repo”来对性能进行分组的。比方咱们驰名的 Linux 操作系统的“内核”（kernel）就有一个独立的“repo”(通常咱们称之为“仓”)。
如果你发现了一个内核的问题，或者需要，那么就须要找到内核相干的 repo 地址：https://gitee.com/openeuler/k…
它的界面这个样子。
其中红圈里大家能够看到 Issues 这个字样，这就是咱们所有问题 &bug& 需要的入口了。点进去当前能够看到：
红圈地位的按钮就是咱们建设一个新的 Issue 的入口。
进入当前，就能够提交 issue 了，有分类栏来阐明这个 issue 属于什么类别。
在这里，可能会有一些同学们会问：为什么没有一个 bugzilla？这是一个拷问灵魂的问题，是呀，为啥没有建设一个工程师们更为相熟的 bugzilla 呢？我没有方法给出一个正当的解释，不过目前看越来越多的我的项目都逐渐通过 issue，PR 等机制来治理我的项目，如果再独立构建一个 bugzilla 零碎，那么和 PR，Merge 合入等的工作就须要进行交联，复杂度会减少，因而目前咱们还是抉择通过 issue 来治理 bug 和需要。
这里有一个小问题，我的问题须要提交到哪里去呢？
Issue 的归宿
总体来说，提交 issue 分如下几类：
- 具体软件的问题间接提交到相干的软件 repo 中，比方下面所提到的 kernel 的 repo 中。
- 社区中的一些基础设施用的不爽，比方网页看起来不悦目等，提交到 https://gitee.com/openeuler/i…，基础设施组。
- 如果是一些社区治理方面问题，例如技术选型，软件的减少，删除，gnome 和 KDE 哪个更图形界面原教旨主义一些等问题能够提到 https://gitee.com/openeuler/c…。
- 如果你切实不晓得该提到什么中央，就通通提交到 https://gitee.com/openeuler/c…，这里会为你排忧解难。
更为具体的 issue 提交流程能够参见如下的业余解说。
https://gitee.com/openeuler/c…
参加形式二：修复 bug
在社区里，通常咱们心愿提出问题并同时解决问题，如果有一个问题，当然最好的状况是同时提供问题解决的 patch 补丁。咱们以社区的轻量化容器引擎 iSulad 为例，https://gitee.com/openeuler/i…，假设咱们须要为 iSulad 提交一个 patch 补丁，根本流程如下：
第一步：建设本人的分支
在红圈处先要 Fork 一个“分支”到本人的账号下。如果大家不分明 fork 的含意，倡议学习一下 git 的应用办法。在这里要提一句，无论如何，古代工程师要了解 git 的开发模式，不理解 git 在当代简直会举步维艰。
第二步，批改代码并生成 Pull Request(简称 PR)
当 fork 结束当前，大家能够在下图的红圈 1 中发现，目录曾经从 openEuler 切换成了本人的账户。
接下来，就能够在本人的“分支”上进行代码的批改了。
批改完当前，点击红圈 2 中的 +Pull Request，这可能是提交代码中最要害的一个步骤，这里会正式生成一个 patch 并送到 https://gitee.com/openeuler/i…。
比方我批改了一个函数，减少了一行 printf(“hello, world”)这行代码。那么 PR 看起来就是这样的：
你须要为这个 PR 起一个名字，同时填写一个阐明。别离是红圈 1 和 2，最初确定 patch 没有问题当前，点击红圈 3 中的“创立”按钮提交。
你会在 openEuler/iSulad 上看到你所提交的 PR，红圈一表明你提交的 PR 曾经进入了 iSulad 的社区，红圈 2 中的数字 228 是这个 PR 的编号。同时这个 PR 的 URL 是：https://gitee.com/openeuler/i…
至此，作为一个 patch 提交者的工作就做完了，你剩下所要做的事件就是急躁的期待 iSulad 开发组的 maintainer 来审核你的 patch，比方我置信明天早晨他会十分惊讶，谁提交了这么一个 stupid 的 patch，而且公然用 useless demo 这样的 PR 题目来挑战他软弱而敏感的 maintainer 神经。
因而，你的 PR 可能有三种命运：
- 被 iSulad 社区承受。
- 被 iSulad 社区仁慈的回绝。
- 提出修改意见，批改后再提交 PR。goto 1
不仅仅是能够提交代码的 PR，任何批改，甚至是为 readme 修改了一个拼写错误，所遵循的流程都一摸一样。
更粗疏，更业余的介绍请参考：
https://gitee.com/openeuler/c…
这里有一步步的教程疏导大家来提交。
另外，PR 的提交也在很大水平上体现了提交者的业余能力和亲和力。Be nice 很重要，上面的链接能够帮忙大家了解如何更优雅的提交一个 PR。
https://gitee.com/openeuler/c…
好了，祝贺您，至此，您的第一次真正意义上的社区开发之旅就画上了一个完满的句号。
让咱们进入下一个挑战环节，为 openEuler 减少一个新的软件包。
参加形式三：奉献软件包
在可能为 openEuler 奉献一个软件包之前，须要咱们的开发者了解两个根本的概念：
- 什么是 Linux 的软件包。或者说 Linux 操作系统是怎么组织的。
- 如何制作一个软件包。
OS 是怎么组织的
显然这是一个十分微小的话题，可能须要写一本书来讲 OS 是怎么组织，怎么构建进去的。在这里我只能简要的给大家介绍一下。
实际上，一个 OS 零碎的组成既简单，也简略。
何所谓简略呢，其实 OS 实质上就是一堆安装包的大杂烩，就相似咱们不管应用 Windows 也好，应用 Android 也罢，或者应用 Linux，咱们都经验过“装置”这个概念，就是从网上，或者是从“仓库”中下载一个安装包，而后装置到零碎上，所以大家能够看到装置的“进度条”。实际上，一个 OS 的装置过程和在 andorid 上装置微信的情理一摸一样。只不过所谓的装置 OS 是须要一次性的要把几千个软件包依照肯定的程序装置到机器中。
那么 OS 所谓的组织很简单呢，大家能够设想以下，几千个软件，他们之间会有很多的交联关系，通常咱们叫做“依赖关系”，就好比，如果你想用微信小程序，那么前提是必须先得有微信，那么装置微信小程序的前提就是必须要先装置微信。因而，即便咱们思考一个 OS 的装置过程，其实也是非常复杂的，必须要准确的计算哪些软件须要先装置，哪些须要后装置。随着零碎的收缩，那么这些软件包之间就造成了简单的网状关系。即便咱们这些行业内的人都为此头痛不已。
讲了这么多，和咱们的 openEuler 社区开发有啥关系呢？其实，下面的解说是要让大家了解，任何 OS 的根本整机就是软件包，就相似组成人体的根本整机是细胞一样。这一个个软件包就是形成 OS 的一个个根本整机。
在 Linux 的世界，有两种根本的安装包格局：
RPM
这个格局是 redhat, suse, WindRiver, openEuler 等所选用，目前在企业市场，根本是以这些厂家为主，因而 rpm 格局在商用企业市场用的比拟多。
Deb
这个格局是 debian, Ubuntu, android 应用的，目前在 desktop，终端侧用的比拟宽泛。
这两种格局自身没有什么优劣之分，只是不必厂商的抉择而已。当然，对于客户，开发者来说，世界被割裂成为两个互不兼容的局部总归是一种不必要的仁慈。对于这个问题社区也有不同的尝试，但目前为止还没有呈现某个大一统的软件包格局可能终结这个决裂的世界。
不过幸好咱们有容器，很大水平上，容器的呈现缓解了这个问题。那将来能不能找到一条优雅的技术路线将这些不兼容，将这些简单的软件包的依赖带来的诸多苦楚一并解决掉呢？我把这个问题留给本文的爱好者吧，兴许在你们两头就会呈现这样的“历史终结者”。
所以，一个软件从源代码到能进入到咱们的 OS 装置光盘中，要经验三个步骤。
第一步：
源代码开发阶段，也就是写程序的阶段。这个阶段能够在任何中央，能够在 github，gitlab, gitee 等代码托管平台上，也能够是本人的笔记本电脑上。
第二步：
将代码编译，生成二进制可执行程序。并且制作 RPM 软件包，其中“制作 RPM”的过程实际上也是一种“编程”，只不过应用的是一种定义好的脚本语言，“程序”是一种叫做 spec 的文件。讲真，spec 的编写是十分不合乎老派程序员思维的，那种分段式的，跳跃式的，宏式的写法相对挑战老派程序员的神经。所以，咱们有很多很好的程序员，然而却很少有程序员能将一个程序真正制作成一个 rpm 包（或者 deb 包）。心愿大家能挑战一下本人，成为一个 RPMer。真的，不难，然而够你慌手慌脚一阵的。
咱们有一个 rpm 的编写标准，能够供大家参考。
https://gitee.com/openeuler/c…
第三步
将这些 rpm 包放在 iso 中，做成装置光盘。这一步个别的工程师不必感知，后盾有自动化的零碎来残缺整个工作，而且相干的工具咱们也会开源到 openEuler 中。也就是说，后续任何人都能够简略的为本人构建一个 My Linux。
那就让咱们看看如果你有一个我的项目在 github 上，咱们如何将它最终转变成为装置光盘上的一个软件包吧。
首先，你得有一个组织
人生存在社会中，无时无刻不属于某个组织，并受到一些人的领导，比方白天，你须要属于某一个公司组织，早晨，你须要属于一个家庭组织。
社区也一样，在你想要把一个软件做成软件包放到 openEuler 零碎中之前，你须要明确两件事件：
- 你本人属于哪个组织？
- 你要退出的这个软件包属于哪个组织？
在 openEuler 社区中，它的根本“组织”单元是 SIG 组，也就是 special interest group，我至今没有弄明确为什么“趣味”要加上“非凡”这个极易产生歧义和联想的前缀。不过 anyway，如果你想有归属感，你有两种抉择：
- 寻找到和你具备同样“非凡喜好”的小组，而后申请加入。
- 你的喜好太“非凡”以至于目前还没有气味相投的人，本人申请建一个。
openEuler 所有的 SIG 组都在 https://gitee.com/openeuler/c…，大家能够参考。
如果你有志愿，同时也展现了对某些“非凡喜好”有着深厚的积攒或者惊人的天才，那么欢送你参照 https://gitee.com/openeuler/c…。我不得不说，这个流程不光看起来有一些简单，也不敌对，实际操作起来也是这样的。但我置信这难不倒码农，咱们不就是为了制作这些简单和不敌对而生的吗！
最初一步，当创立完 SIG 的 PR 申请当前，须要到技术委员会 (TC) 的例行会议上进行评审，在 https://gitee.com/openeuler/c…，还有联系方式，大家能够订阅 TC 的邮件列表来获取一些动静，特地是例会的信息。
既然说到了 TC（技术委员会），咱们就简要讲一下 openEuler 的组织构造吧。
组织构造
openEuler 是一个齐全凋谢的组织架构，而且非常简单，https://gitee.com/openeuler/c…。
我想这副图曾经说的很分明了。
开始干活，先要弄明确干什么
当然，即便你齐全不属于任何一个 SIG 组，实践上也能提交一个软件包到 openEuler 中，只是被承受的概率绝对较低而已。其次要起因是很难来评估相干提交的品质，SIG 组很大的意义就在于一些业余方面的人可能为每次提交做出品质的保障。
软件包自身必须是要属于某一个 SIG 的。以我本人罕用的一个软件包为例，我每次写完程序当前，都总会执行一下 cloc 这个命令，看一下明天又新增了多少行代码，以期取得一下码农与生俱来的成就感，并中和一下写 PPT 带来的充实和乏力感。
显然 cloc 是一个开发类的工具，帮忙码农统计代码行，侥幸的是，领有同样“非凡喜好”的人并不在少数，他们建设了一个 dev-utils 的 SIG 组，https://gitee.com/openeuler/c…，咱们能够将 cloc 这个软件归属于这个 SIG 组。
如何把大象放到冰箱里
一般来说，减少一个软件包到 openEuler 中，须要如下的几个大步骤
- 让零碎为你的 cloc 软件包建设一个“仓”，也就是 git 仓。
- 上传制作 cloc 软件包所须要的“整机”
- 将这个软件系统退出到 openEuler 的自动化编译系统中，由零碎自动化构建出软件。
建仓
建仓其实就是提交一个 PR，一般来说须要批改三个文件。
- https://gitee.com/openeuler/c…
- https://gitee.com/openeuler/c…
- https://gitee.com/openeuler/c…
批改第一个文件 README.md 将你要退出的 cloc 软件的名字和地址放上去。
批改 sigs.yaml 文件，将 cloc 软件减少到 dev-utils 这个 SIG 分组上面。
批改 src-openeuler.yaml 将 cloc 减少到 src-openeuler 里。
你要做的就是照猫画虎的把这三个文件批改了，而后提交 PR 就能够了。剩下的就是期待“命运的裁决”。
当申请的后果被批准当前，你所须要的“仓”就会被零碎主动建设起来，对于 cloc 来说，它的代码仓的地位在 https://gitee.com/src-openeul…，这是 PR 被批准当前由零碎主动为我建设的。
剩下的工夫，你就能够开始真正上传制作 cloc 软件的原材料了。
上传软件包
一般来说，一个软件只须要上传两个“原材料”就足够制作一个软件包了。如下图所示：
第一个资料：首先要上传这个软件包的 spec 文件，也就是通知构建零碎如何编译，制作 cloc 这个软件包。
第二个资料：cloc 的源代码压缩包。
其它整机：如果 spec 中须要有 patch，那么也须要把相干的 patch 文件上传到仓中。
上传完毕一个软件包所须要的原材料，下一步就是要把这些原材料退出到构建零碎中，使之可能被真正编译，生成一个理论的软件包。
退出构建零碎
openEuler 当初应用 obs 作为构建工具零碎，大家能够参考上面的这个链接把本人的软件退出到 obs 中
https://gitee.com/openeuler/c…
退出到构建零碎中，就意味着你的软件能够被零碎主动编译，主动生成 rpm 包，继而在后续的 openEuler 发行版本中呈现。
TIPS
在整个过程中有几点须要开发者要留神：
- 可能本地构建：提交的软件包首先要在本人的笔记本，或者服务器上可能编译通过。也就是如果你的软件包在本地无奈构建胜利，那么上传到 openEuler 社区也不会构建胜利。因而。咱们倡议最好能下载最新的 openEuler 版本，装置当前通过 rpmbuild 等命令来进行构建验证。
- 保障软件包可用：软件除了可能被编译和生成软件包，还要能正确运行，因而，在本地环境要保障制作进去的软件包可能：
a) 正确的装置
b) 正确的卸载
c) 正确的降级
d) 软件的性能是失常的。
- 保障多体系架构反对：openEuler 目前反对 x86_64 和 ARM64 两种指令集，因而在构建过程中须要可能保障软件包在这两种环境下都能被正确编译和运行。尽管 ARM64 环境可能并不那么容易获取，但侥幸的是，一般性软件在这两个零碎上没有那么大的差别。
- 保障正确的依赖关系：一个软件通常都须要依赖其它的一些软件能力运行，比方所有软件都须要依赖 glibc 这个库来执行，一些简单的软件可能会依赖很多软件包来提供性能。这些软件包可能曾经在 openEuler 社区中有了，也可能没有。如果没有，那么就须要同时在 openEuler 社区中将这这些软件包补齐才行。比方 cloc 这样一个小软件，缺须要依赖如下的几个 perl 的软件包：
也就是说在提交 cloc 软件包的同时，也须要同时提交这几个软件包，这样能力保障 cloc 可能被零碎正确的编译和构建进去。
- 保障 spec 文件的规范性：要保障 spec 文件是“标准”的，防止将内部的 spec 间接引入到 openEuler 中，因为如前所述，因为抉择包的范畴，依赖关系，版本等都不雷同，同时保障所有软件包 spec 是统一的，请按照后面的 rpm 制作标准中的内容来书写 spec 文件。
因而，制作一个软件包，有的时候远比设想中的要简单一些。但好在这并不是一个难度很大的事件，只须要提交一个软件包，走一遍流程，后续就会驾轻就熟了。
参加形式四：开发新软件
下面讲的过程都是怎么给“他人”的软件提意见，怎么把“他人”做的软件增加到 openEuler 社区。然而每一个真正做软件的人心田都心愿能领有属于本人的作品，那么如何建设本人的作品，如何将本人的作品融入到 openEuler 社区呢？
将本人的作品融入到 openEuler 社区有如下两种办法：
办法一：在其它社区开发，集成到 openEuler 中
假设你曾经在 github，gitlab 或者 gitee 上领有了本人的我的项目，那么只须要依照参加形式三那样，将软件退出到 src-openeuler 这个 repo 仓就能够了。
办法二：在 openEuler 社区中开发，在 openEuler 中集成
另外一种办法是，间接在 https://gitee.com/openeuler 中 …，相似将我的项目“托管”到 openEuler 社区。比方当初社区中的 iSula 和 A -Tune 这样的我的项目就是这样的模式。
至此，我置信所有人都能明确了为什么 openEuler 会建设两个仓：
https://gitee.com/openeuler
https://gitee.com/src-openeuler
openeuler 这个仓是存储所有“原生态”的软件，也就是为原创性的软件提供一个展现的舞台，或者是一个孵化器平台。
而 src-openeuler 则是为 openEuler 的 release 发行版提供生成 rpm 包等构建信息等的中央。
因而，当一个很有幻想，很有情怀的工程师忽然有一天有了一个很棒的 idea，那么他能够按照上面的过程来深度参加到 openEuler 中。
- 在 TC 委员会的例会 meeting 中申请一个开源我的项目，比方项目名称叫做“broken_dream”。
- 如果 TC 委员会认为这是一个很好的 idea，并且认为值得为破碎的幻想提供一个机会，那么咱们会在 https://gitee.com/openeuler 中 …，网址就是 https://gitee.com/openeuler/b…
- 这个我的项目在 openeuler 中继续开发和孵化，直到有一天，大家认为 broken_dream 曾经足以成熟到为所有人提供破碎的幻想服务了，那么就能够在 src-openeuler 中建设一个仓，为 broken_dream 提供相干的 spec 文件，制作成为一个 rpm。
- 最终 broken_dream.rpm 会随着 openEuler 的公布版本走遍全世界，为世界人民提供 broken_dream 性能。
我始终认为，一个工程师，在他的职业生涯中，至多要有一个，哪怕只有一个我的项目和他本人的名字是非亲非故的。只有这样，能力在孙子，孙女骑在咱们背上，问咱们这辈子做的最棒的事件是什么的时候，咱们能够让他们爬下来，而后直起身，看着他们天真无邪，对将来充斥神往的大眼睛，认真的问他们：你晓得 broken_dream 的作者是谁吗？
最初，我要感激 openEuler 社区中每一个贡献者，特地是文档的撰写者们，文档对于码农们来说永远是苦楚的源泉，但正是各位文档的撰写者的辛勤工作，才使得本文可能有一个机会为大家出现一个残缺的 openEuler 参加之旅。