最直观的方式是访问openEuler官方repo，看看发布件。
另外一种方式，就是访问openEulerOBS上的构建工程，可以知道每个版本里包含哪些软件，当前的构建状态是啥样的。
openeuler源码仓库管理：
openeuler/community仓库下，以下三个文件比较重要：
通过修改这几个文件，来新增、删除软件包仓库，来给相应的软件包划分sig，从而实现sig的owner对软件包的权限管理。
SIG就是SpecialInterestGroup的缩写，openEuler社区按照不同的SIG来组织，以便于更好的管理和改善工作流程。
openEulerSIG维护策略
上图是openEuler社区开发指引图。
全景图中涉及的规范：
建议：
包括但不限于：
结合前面的开发者全景图，可以分解成以下动作：
注意事项：
检视代码:
对于贡献者，为了使您的提交更容易被接受，您需要：
SIG列表：gitee.com/openeuler/community/tree/master/sig TC邮件列表：gitee.com/openeuler/community/tree/master/zh/technical-committee PR模板：gitee.com/openeuler/community/tree/master/sig/sig-template 提交示例：gitee.com/openeuler/community/pulls/398找到您感兴趣的SIG或项目
找到您感兴趣的SIG组，可以帮助您在正确的地方提出问题，并得到更快的社区响应。
当前发现openEuler社区缺少你需要的软件时，你可以尝试动手为社区贡献软件包。这里不再赘述OS是如何由linux软件包组成的，以及如何制作一个rpm包。这里着重讲解贡献软件包的流程。
原本是作为发行版openSUSE专用的rpm打包的平台，后续扩展为面向多发行版、多架构、多格式的打包发布平台。
与koji的不同
与koji只管理包（包括源码包与二进制包）仓库不同，OBS同时管理着源码与包两个仓库。koji是从一个包编译完成后开始接手，根据包的NVR（Name-Version-Release）确定包的位置，在编译验证后入库保存。而OBS是从源码阶段开始管理，它拥有自己的包版本标记与changelog日志。OBS可以像git一样保存源码的历史版本，对源码进行分支管理。并生成各版本的二进制包与源码包。
换句话说，OBS可以同时实现koji和git的功能。>OBS接受源码的格式与git普遍的保存格式并不相同，所以OBS无法完全取代git。
OBS可以生成rpm、deb等格式的包，而koji只适用于rpm格式。
方便测试框架、构建工程调用。
安装osc
这里以Fedora30为例：
执行dnfinstallosc命令安装osc。
配置openEuler的OBS
有很多方法可以将osc链接至openEuler外网的OBS：
注册OBS账号
oschelp是帮助指南。类似git命令。
ListExistingContentontheServer
oscls#listprojectsosclsApache#listpackagesinaprojectosclsApacheflood#listfilesofpackageofaprojectCheckoutContent
osccoApache#entireprojectosccoApacheflood#apackageosccoApachefloodflood.spec#singlefileUpdateaWorkingDdirectory
oscuposcup[directory]oscup*#fromwithinaprojectdir,updateallpackagesoscup#fromwithinaprojectdir,updateallpackagesANDcheckoutallnewlyaddedpackagesUploadChangedContent
oscci#currentdiroscci[file1][file2]#onlyspecificfilesoscci[dir1][dir2]...#multiplepackagesoscci-m"updatedfoobar"#specifyacommitmessageChecktheCommitLog
osclogShowthestatus(whichfileshavebeenchangedlocally)
oscstoscst[directory]Ifanupdatecannotbemergedautomatically,afileisin'C'(conflict)state,andconflictsaremarkedwithspeciallines.Aftermanuallyresolvingtheproblem,useoscresolved*FILE*.
MarkfilestobeAddedorRemovedontheNextCheckin
oscaddfoooscrmfooAddallNewFilesinLocalCopyandRemovesallDisappearedfiles
oscaddremoveGenerateadifftoviewthechanges
oscdiff[file]ShowtheBuildResultsofthePackage
oscresultsoscresults[platform]ShowtheLogFileofaPackage
(youneedtobeinsideapackagedirectory)
oscbuildlog[platform][arch]在本地机器上构建
oscbuild[platform][arch][specfile][--clean|--noinit|...]以abuild用户进入chroot环境，方便调试
oscchroot[platform][arch]如何创建自己的工程，package配置Project
两种方法：网页操作、命令行操作
在obs主页点击右上角
依次进入HomeProject->Repositories->AddfromaDistribution。
按上图所示填写基础配置，并在Name栏填写喜欢的名字。
在选择后后退至Repositories界面，可以看到如下图所示的环境：
执行命令：oscmetaprj-e[project名]，会看到类似如下文本：
其中，1.repository标签为仓库标签，可添加此项添加编译时的基础环境2.Path标签为可用包路径标签，需手动添加发行版包路径。如需要额外依赖，也可以单独添加。3.Arch标签为编译架构，可同时添加多个。
例如：
进入Project目录：cd[project名]
新建Package：oscmkpac[package名]
进入Package目录并将下载源码以【tar包、所有patch、spec文件、其他source文件】格式放置：
向新创建的package中添加以上文件：oscadd*
将更改上传至服务器：osccommit
在这里可以注明本次上传的简短介绍，用:wq保存并退出
之后就可以在网页上等待编译并查看结果了。
查看包状态与下载包
您可以在Project与Package主页右侧看到当前编译状态
您可以点击编译平台->Gotodownloadrepository到达编译仓库，获得此Project的repo源与所有编译成功的package。
更新包
进入project文件夹：cd[project名]
更新本地代码为最新代码：oscup
进入package目录，使用oscadd命令将新文件添加到package，修改spec文件后使用osccommit命令上传新版本。
分为两部分：
SourceServices是用于以可靠方式验证，生成或修改源的工具。它们被设计为最小的工具，并且可以按照经典UNIX设计的强大思想进行组合。
源服务就像是系统中的函数，我们可以通过运行脚本调用它；而脚本就是Package中的_service文件。
创建使用源服务的Package
编辑_service文件
最基础的_service文件将会如下所示：
为了实现“利用源服务直接获取git源码并编译成包”这个目标，
我们的_service应该类似于这样（以下格式请根据具体情况选择合适的顺序）：
tar_scm会将链接url中的仓库下载下来并打包为tar文件，文件包命名格式为：
[Name]-[Version].[commit_timestamp].tar
可选参数：
在OBS官方服务器中，tar_scm服务由于在空间利用率上表现不佳，已被obs_scm、tar服务取代，但openEuler的外网OBS暂时还不支持obs_scm，所以这里选择tar_scm。
extract_file可以从tar包中提取文件，具体需要提取什么文件取决于git仓库中的文件格式。
一般来说我们可以将打包需要的内容分为四大类：
对于git仓库来说，一般会将所有文件放到仓库的根目录。
此时我们需要将spec文件、patch文件、源文件提取出来，源码则留在tar包中等待之后的服务将其压缩打包。
对于OBS仓库来说，为了方便OBS系统使用，人们已经对源码进行压缩打包。
此时我们需要将所有文件提取出来并省略之后的压缩打包环节。
参数：
recompress会对指定文件进行压缩
会将spec文件中的Version替换为obs_scm时的
[Version].[commit_timestamp]spec文件中可以以
helloworld-%{version}.tar.xz格式定位源码包。
等待编译完成
当状态显示为blocked时，表明源服务正在运行。当源服务运行完毕时会正常开始打包过程。
SourceServices在实际场景中的应用
首先，我们在git仓库中以：**spec文件、patch文件、源码tar包的格式上传并管理源码。
在OBS系统中建立对应包并以一下格式定义_service文件：
在这之后，OBS系统会帮助我们完成编译与打包的环节。
在写此文时，OBS系统还不支持gitee格式的webhook，所以以下内容为使用github仓库实现。
obs可以创建令牌（token），当令牌被触发时，OBS会运行源服务。
将网址与令牌添加到git仓库的webhook列表中，就可以在git仓库中实现触发源服务，进而更新OBS中的包版本。
具体步骤：
创建专属包的OBSToken（OBS令牌）：
打开git仓库网址（以github为例）：
打开仓库->Setting->Webhooks
在PayloadURL中以：
在Secret中填入令牌秘匙，按需求选择trigger类型，保证Webhook为Active状态。