简介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....虽然协议并不复杂，但作为一个coder，我通常对这样的法律文件是免疫的。我们甚至需要给你不会多花一分钟看一份你自己赔钱的保险合同。这种需要自己付出的条款，怎么可能会注意呢？更重要的是，如果一个编码员看懂了法律文件，他还是编码员吗？虽然这很大程度上是我们码农的现状，但我还是建议大家仔细阅读协议，了解权益范围。我们是一个开源的openEuler社区。原则上，我们只接受有开源协议的软件。哪些开源协议是社区认可的开源协议？您可以参考以下网址。本网站列出的开源协议均为openEuler社区可接受的协议。https://opensource.org/licens...对于社区本身，我们默认使用mulanV2协议，https://opensource.org/licens...，这是一个非常友好的开源协议，大家欢迎更多人使用本协议开发开源软件。我能做什么在签署了CLA协议并了解了我们认可的开源协议的范围之后，我们需要完成社区注册。由于openEuler本身是对gitee.com开放的，所以大家需要在gitee上有一个账号。我们也衷心希望gitee能够成长为世界一流的代码托管平台。完成这些过程后，您需要考虑可以在社区中做什么。参与社区的方式和形式有很多种。如果归纳起来，大致有以下四类：提交一些需求，或者bug。或者在使用openEuler的过程中发现了一些问题，然后需要在社区中提出这个问题。为社区修复bug是对社区更高层次的参与。在这个级别，参与者实质上是以开发人员的身份进入社区的。一般来说，我们提倡除了提出问题，更期望大家去解决问题。贡献软件包，发现openEuler少了一个软件包，帮助openEuler补上这个软件包。其实贡献软件包的过程就是帮助openEuler提供更丰富功能的过程。希望在大家的参与下，openEuler能够成为一个“无所不包”的软件生态。开发新的软件，有自己的一些想法，独立开发一个全新的软件，把这个软件贡献给openEuler社区，成为openEulerrelease的一部分。下面我们就来一一了解一下这四种参与方式是如何进行的。网站和社区在详细讨论这四种参与方式之前，我先给出三个URL链接。https://openeuler.org/https://gitee.com/openeuler/https://gitee.com/src-openeuler第一个网址是openEuler的入口，是你获取一些通用信息的地方。已经提到了。而我们真正所谓的“社区”，体现在2和3这两个URL上。这两个URL是相互链接的，看起来是这样的：它们看起来很相似，为什么会有两个URL？两者之间的分工是什么？我们会在后续的讲解中慢慢为大家讲解。无论如何，这两个站点及其中的内容将成为社区工作的主要场所。虽然人机界面不友好，但相信这对码农来说问题不大，因为码农的世界从来就不是友好的。参与方式一：提交需求&bug参与社区最基本的方式当然是先使用社区对象，看看有什么需要改进的地方。提出一些宝贵的建议和意见。这几乎是参与社区的最简单方式。在社区中，我们通过“issue”机制提交问题。但是在提交之前，提交者首先要明确这个issue要提交给谁。在社区中，我们使用“repos”来对功能进行分组。比如我们著名的Linux操作系统的“内核”（kernel）就有一个独立的“repo”（通常我们称之为“仓库”）。如果你发现内核问题或者需求，你需要找到内核相关的repo地址：https://gitee.com/openeuler/k...它的界面是这样的。其中，可以看到红圈中的Issues这个词，这是我们所有problems&bugs&needs的入口。点进去之后可以看到：红圈里面的按钮就是我们新建Issue的入口。进去之后就可以提交issue了，里面有个category栏，说明这个issue属于什么类别。说到这里，可能有同学会问：为什么没有bugzilla？这是一个拷问灵魂的问题，是的，为什么不创建一个工程师更熟悉的bugzilla呢？我没有办法给出一个合理的解释，但是目前越来越多的项目逐渐通过issue、PR等机制来管理项目。如果我们独立搭建一个bugzilla系统，那么整合PR和Merge的工作就很容易了。需要交叉链接，复杂度会增加，所以我们还是选择通过issue来管理bug和需求。这里有一个小问题，我的问题应该提交到哪里呢？issue的去向一般来说，issue的提交分为以下几类：具体的软件issue直接提交到相关的软件repo，比如上面提到的kernelrepo。社区有些基础设施不舒服，比如网页看起来不顺眼等，提交到https://gitee.com/openeuler/i...，基础设施组。如果是一些社区治理问题，比如技术选型，软件增删改查，gnome或者图形界面比较原教旨主义的KDE等等，可以参考https://gitee.com/openeuler/c...。如果你真的不知道在哪里提，就把它们都提交到https://gitee.com/openeuler/c...，这里将解决你的问题。更详细的issue提交流程，请参考以下专业讲解。https://gitee.com/openeuler/c...参与方式二：修复bug在社区中，通常我们想边提问边解决问题。如果出现问题，当然最好的情况是提供解决问题的同时打补丁补丁。我们以社区的轻量级容器引擎iSulad为例，https://gitee.com/openeuler/i...，假设我们需要为iSulad提交补丁，基本流程如下：第一步：创建你的红圈内自己的分支必须先Fork一个“分支”到自己的账户。如果你不知道fork的意思，建议学习一下git的使用方法。这里要提一下，无论如何，现代工程师都必须了解git的开发模式。如果他们不懂git，在现代几乎是不可能前进的。第二步，修改代码，生成PullRequest（简称PR）。fork完成后，可以在下图中红圈1处发现目录已经从openEuler切换到自己的账号下了。接下来，就可以在自己的“分支”上修改代码了。修改完成后，点击红圈2中的+PullRequest，这可能是提交代码最关键的一步。这里官方会生成一个patch，发到https://gitee.com/openeuler/i....比如我修改了一个函数，加了一行printf("hello,world")。然后PR看起来是这样的：你需要给这个PR起一个名字并填写一个描述。分别是红圈1和2。确认补丁没有问题后，点击红圈3中的“创建”按钮提交。你会在openEuler/iSulad上看到你提交的PR，红圈1表示你提交的PR已经进入iSulad社区，红圈2中的数字228就是这个PR的编号。同时，本次PR的URL为：https://gitee.com/openeuler/i...至此，补丁提交者的工作就完成了，你所要做的就是耐心等待iSulad开发组的maintainer以review你的patch为例，我相信他今晚会很惊讶，谁提交了这么蠢的patch，并公然用无用的demo等PR话题挑战他脆弱敏感的maintainer神经。因此，您的PR有三种可能的命运：被iSulad社区接受。遭到iSulad社区的残酷拒绝。提出修改意见，修改后提交PR。goto1不仅仅是一个可以提交代码的PR，任何修改，甚至修复readme的错字，遵循的过程都是完全一样的。更详细专业的介绍请参考：https://gitee.com/openeuler/c...这里有一步一步的教程，指导大家提交。另外，PR的投稿也在很大程度上体现了投稿人的专业能力和亲和力。Benice很重要，下面的链接可以帮助你了解如何更优雅地提交PR。https://gitee.com/openeuler/c...好了，恭喜你，至此，你的第一次真正的社区开发之旅就完美结束了。让我们继续下一个挑战，向openEuler添加一个新包。参与方式三：贡献软件包在能够向openEuler贡献软件包之前，我们的开发者需要了解两个基本概念：什么是Linux软件包。或者Linux操作系统是如何组织的。如何制作一个包。操作系统是如何组织的显然是一个非常庞大的话题，可能有必要写一本书来介绍操作系统是如何组织和构建的。在这里我只能给大家做一个简单的介绍。事实上，OS系统的组成既复杂又简单。所谓简单，其实OS本质上就是一堆安装包的大杂烩，类似于我们无论是使用Windows、Android还是Linux，我们都经历过“安装”这个概念，即从上网，或者从“仓库”下载一个安装包安装到系统上，这样就可以看到安装的“进度条”。其实一个OS的安装过程和在andorid上安装微信是一模一样的。只不过所谓的OS安装需要一次把上千个软件包按照一定的顺序安装到机器上。那么所谓的OS的组织就很复杂了。可以想象，有成千上万的软件，它们之间会有很多交联关系。通常我们称之为“依赖关系”。比如你要使用微信小程序，那么前提是必须先有微信，所以安装微信小程序的前提是必须先安装微信。因此，即使我们考虑一个OS的安装过程，其实也是非常复杂的。需要准确计算出哪些软件需要先安装，哪些需要后安装。随着系统的扩展，这些软件包之间形成了复杂的网络关系。甚至我们这些业内人士也在为此苦苦挣扎。说了这么多，跟我们openEuler社区发展有什么关系呢？其实上面的解释是为了让大家明白，任何操作系统的基本部分都是软件包，就像构成人体的基本部分是细胞一样。这些软件包是构成操作系统的基本部分。在Linux的世界里，有两种基本的安装包格式：RPM是redhat、suse、WindRiver、openEuler等使用的格式，目前在企业级市场，基本都是这些厂商的主要格式，所以rpm格式是用于商业企业市场。更多的。Deb格式被debian、Ubuntu、android使用，目前广泛用于桌面端和终端端。这两种格式本身没有区别，只是制造商不必选择它们。当然，对于客户和开发者来说，将世界分割成互不相容的两部分总是不必要的残忍。社区有不同的尝试来解决这个问题，但到目前为止还没有一个统一的包格式来结束这个分裂的世界。幸运的是，我们有容器。很大程度上，容器的出现缓解了这个问题。未来，我们能否找到一条优雅的技术路径来解决这些不兼容以及这些复杂软件包的依赖带来的痛苦呢？我把这个问题留给本文的爱好者，也许你们中间会有这样的“历史终结”。所以，一个软件从源代码到能够进入我们的操作系统安装光盘需要经历三个步骤。第一步：源代码开发阶段，即编写程序阶段。这个阶段可以在任何地方，在github、gitlab、gitee等代码托管平台上，或者在您自己的笔记本电脑上。第二步：编译代码生成二进制可执行程序。而制作RPM软件包，“制作RPM”的过程其实也是一种“编程”，只是使用了一种定义明确的脚本语言，而“程序”就是一个名为spec.php的文件。说实话，spec的写法很不符合老派程序员的思维。分段式、跳跃式、宏式的写法，绝对挑战老派程序员的神经。所以，我们有很多优秀的程序员，但是真正能够把一个程序打成rpm包（或者deb包）的程序员却很少。希望大家可以挑战自我，成为RPMer。真的，不难，但也够你折腾一阵子了。我们有一个rpm编写规范供您参考。https://gitee.com/openeuler/c...第三步，将这些rpm包放入iso中制作安装光盘。一般工程师不需要感知这一步。后台有一个自动化系统来完成整个工作，我们也会将相关工具开源到openEuler中。换句话说，未来任何人都可以简单地为自己构建一个MyLinux。那么让我们看看如果你在github上有一个项目，我们如何才能最终把它变成安装光盘上的一个包。首先，你要有一个组织人，他生活在社会中，始终属于某个组织，受某些人领导。比如白天，你需要归属于某个公司组织，晚上，你需要归属于某个家庭组织。社区也是如此。在你想做一个软件包进入openEuler系统之前，你需要明确两件事：你属于哪个组织？您要加入的套餐属于哪个组织？在openEuler社区中，它的基本“组织”单位是SIG群，即特殊兴趣小组。到现在还没搞明白为什么“兴趣”要加“特”的前缀，很歧义，很容易联想。但无论如何，如果你想要有归属感，你有两个选择：找一个和你有相同“特殊兴趣”的团体，然后申请加入。你的爱好太“特别”了，目前还没有志同道合的人，申请自己建一个。openEuler的所有SIG群都在https://gitee.com/openeuler/c...，大家可以参考。如果你愿意并且已经表现出对某些“特殊爱好”的深厚积累或惊人的天赋，那么欢迎你参考https://gitee.com/openeuler/c...。不得不说，这个过程不仅看起来复杂且不友好，实际操作起来也是如此。不过我相信这不会给码农们带来麻烦，我们不是天生就让这些变得复杂和不友好的吗！最后一步，创建SIGPR申请后，需要去技术委员会（TC）例会进行审核，网址为https://gitee.com/openeuler/c...，以及联系方式，您可以订阅TC的邮件列表以获取一些更新，尤其是例会信息。既然提到了TC（TechnicalCommittee），那我们就简单说一下openEuler的组织架构。组织结构openEuler是一个完全开放的组织结构，而且非常简单，https://gitee.com/openeuler/c...。我认为这张照片非常清楚。要开始工作，您必须首先了解自己在做什么。当然，即使你不属于任何SIG组，理论上也可以向openEuler提交软件包，但被接受的概率比较低。主要原因是相关投稿质量难以评价。SIG组的重要意义在于有专业的人来保证每次投稿的质量。包本身必须属于一个SIG。以我经常使用的一个软件包为例。每次写完一个程序，我总会执行cloc命令，看看今天增加了多少行代码，以此来获得一个coder的内在成就。感受，并中和写PPT带来的空虚和疲惫。显然cloc是一个帮助coder统计代码行数的开发工具。幸运的是，有同样“特殊爱好”的人不在少数。他们建立了一个dev-utilsSIGgroup，https://gitee.com/openeuler/c...，我们可以把软件cloc归于这个SIG组。如何把大象放进冰箱一般来说，在openEuler中添加一个软件包需要以下几大步骤，让系统为你的cloc软件包创建一个“bin”，即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-utilsSIG组。修改src-openeuler.yaml将cloc添加到src-openeuler。你所要做的就是根据猫和老虎修改这三个文件，然后提交PR。剩下的就是等待“命运的审判”了。当申请结果通过后，系统会自动建立您需要的“仓库”。对于cloc，它的代码仓库位于https://gitee.com/src-openeul...，这个是PR通过后系统自动帮我创建的。剩下的时间，您可以开始实际上传原材料来制作cloc软件。上传软件包一般来说，一个软件只需要上传两个“原材料”就可以制作一个软件包。如下图所示：第一份资料：首先上传本软件包的spec文件，即告诉构建系统如何编译制作cloc软件包。第二种资料：cloc的源码压缩包。其他部分：如果spec中需要打补丁，那么也需要将相关的补丁文件上传到仓库中。上传软件包所需的原材料后，下一步就是将这些原材料添加到构建系统中，以便实际编译生成实际的软件包。加入构建系统openEuler现在使用obs作为构建工具系统，你可以参考下面的链接将你自己的软件添加到obshttps://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文件是“标准的”，避免直接将外部specs引入openEuler，因为如前所述，因为选择的包的作用域、依赖、版本等不同，并且同时确保所有软件包的规格一致。请按照之前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/openeulerhttps://gitee.com/src-openeuleropeneuler这个仓库存放所有“原生态”的软件，也是为了为原创软件提供展示舞台，或孵化平台。而src-openeuler是为openEuler的release版本提供rpm包等构建信息的地方。因此，当某天一个充满梦想和激情的工程师突然有了一个很棒的idea时，他可以按照以下流程深度参与openEuler。在TC委员会例会上申请一个开源项目，例如项目名称为“broken_dream”。如果TC委员会认为这是一个好主意并且认为值得给BrokenDreams一个机会，那么我们将在https://gitee.com/openeuler...在https://gitee.com/openeuler/b。..这个项目在openeuler中不断的发展和孵化，直到有一天，大家觉得broken_dream已经足够成熟，可以为大家提供碎梦服务了，那么就可以在src-openeuler中建一个仓库，提供broken_dream的相关spec文件并make它变成一个rpm。最终broken_dream.rpm会随着openEuler的发布走遍全球，为全世界的人们提供broken_dream功能。我始终相信，一名工程师在他的职业生涯中必须至少有一个项目，即使只有一个项目与他自己的名字息息相关。只有这样，当我们的孙子孙女骑在我们的背上，问我们这辈子做过的最好的事情是什么时，我们才能让他们爬下来，然后站直，看着他们天真烂漫，对未来充满希望.用渴望的目光，认真地问他们：你知道broken_dream的作者是谁吗？最后，感谢openEuler社区的每一位贡献者，尤其是文档编写者。文档一直是编码人员的痛苦之源，但正是文档编写者的辛勤工作才使这篇文章成为可能。有机会为大家呈现一个完整的openEuler参与之旅。欢迎来到openEuler社区
