有创新版本和LTS（Longtermsupport）版本两条线的版本。
master分支即为当前最新版本开发分支，一旦发布创新版本或LTS版本，
即会基于当前master主干拉出对应版本分支进入维护阶段。
openEuler构建模型：
版本如何构建：
最直观的方式是访问openEuler官方repo，看看发布件。
另外一种方式，就是访问openEulerOBS上的构建工程，可以知道每个版本里包含哪些软件，当前的构建状态是啥样的。
openeuler源码仓库管理：
openeuler/community仓库下，以下三个文件比较重要：
通过修改这几个文件，来新增、删除软件包仓库，来给相应的软件包划分sig，从而实现sig的owner对软件包的权限管理。
SIG就是SpecialInterestGroup的缩写，openEuler社区按照不同的SIG来组织，以便于更好的管理和改善工作流程。
openEulerSIG维护策略
上图是openEuler社区开发指引图。
所有修改和操作通过PR来发起。
全景图中，每个动作都可能涉及规范或指导。将在后面以表格的方式整理呈现。
全景图中涉及的规范：
准备工作
克隆到本地
拉分支
gitcheckout-bmyfeature修改验证提交
gitadd.gitcommit-m"提交原因"推送到码云
gitpush-foriginmyfeature创建PR
访问你的个人主页，选择目标分支，点击+PullRequest来创建一个PR
给PR指派检视人员，及时回复reviewers的意见。
更新PR
码云默认会把个人仓库的分支与目标仓库的对应分支的差异作为一个PR，所以本地对该分支的修改，当push后，自动会更新到PR中。
建议：
不要在master上提交代码，当PR未merge时，强制同步会失败。
包括但不限于：
结合前面的开发者全景图，可以分解成以下动作：
注意事项：
openEuler只接受PR的形式来提交代码，不允许直接向openEuler下的仓库直接push代码。
将代码gitclone到本地，如果你的修改不涉及二进制源码软件包的变化，将所修改的代码做成一个patch，因为仓库是以rpm源码包的格式组织的。
代码reviewers可以针对提交给出自己意见，当他认可你的提交时，会/lgtm来给出ok的意见。
针对别人给出的检视意见。如果涉及修改代码，可以使用gitcommit--amend；gitpush-f来在同一个PR更新PR。
检视代码:
对于贡献者，为了使您的提交更容易被接受，您需要：
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包。这里着重讲解贡献软件包的流程。
再者，由于软件唯一的归属于一个sig，你需要查看当前是否有合适的sig承载，如果没有，需要你按照步骤3申请成立一个新的sig。
该工程下所有软件包成功的构建结果，归档在：
它是以repo源的方式归档，可以直接使用yum安装。
原本是作为发行版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：
修改位于home目录下的osc配置文件：vi~/.oscrc，并写入以下内容：
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状态。