编译服务协同工作
目录
简介
开放式编译服务（缩写：OBS，Open Build Service）提供多种协同工作方法。最简单的方法就是在一个软件包或一个项目里授予多人“写入”权限。这种方法使紧密工作在一起的小团队可以非常快的协同工作。
但是，这种方式在一些情况下不适用：
- 不认识的贡献者没有写入权限，因此无法提交修改。
- 项目组间的彼此信任随着拥有写入权限的人数增加而下降。
- 即使有写入权限的人，也想他们的修改在并入项目前得到复核。
- 一个大项目中持续不断的修改会导致这种情况就是项目永不可能完成到可编译阶段。对基础包的修改会无限期阻碍其他包的编译。
因此，开放式编译服务提供了另外一种贡献方式。你可以在一个分支项目里准备你的修改，之后请求这些修改被并回。
大项目，例如KDE，GNOME，Apache和YaST，经常需要另外一层复核，即提交的修改可以在通过二次审查并入主项目前被归入“测试准备”阶段。openSUSE：Factory（工厂版）就是这样的例子。这个项目给每一个包指定了一个开发项目。开放式编译服务帮助用户针对这些开发项目进行二次开发，并提交他们的修改到那里。开发项目的所有者们可以稍后一并提交所有的修改到openSUSE:Factory。这个过程在这些幻灯片中有多媒体展示。
命令行实例
我们的CLI（命令行客户端）叫做“osc”。你可以在openSUSE:Tools项目中找到最新的版本。
另一个实例（链接为英文） 提到了如何使用网页版客户端（build.opensuse.org）来针对一个项目(PackageKit）进行创建分支（layering），链入（linking），补缀（patching），归并（aggregating）操作。
如何提交修改到别人的软件包？
假设说你想要修改这个包openSUSE:Factory/initviocons，并且稍后将你的工作提交回openSUSE:Factory项目。
下面内容将逐步告诉你应该怎么做。
创建分支软件包
首先，我们创建我们想要在我们的家项目下进行修改的软件包的分支。
# osc branch <source project> <source package> # osc（命令行客户端名） branch（创建分支操作的参数） <source project>（源项目) <source package> （源软件包) osc branch openSUSE:Factory initviocons
这个命令先是创建了一个新的私有“分支项目”在你的home:$yourself:branches（如果它不存在的话），即在你的家项目下创建了一个”branches+源项目名称“的子项目。这个分支项目与源项目拥有相同的编译设定。接下来本命令链入了源项目中你指定的源软件包到你的分支项目下。
许多软件包都有一个指定的“开发项目”。在这种一般情况下，服务器创建的是一个到开发项目的链入而不是源项目的链入。你可以从‘osc branch’命令的输出中看到这些，例如：
# branch a package from factory but which is developed in a different project # 从工厂版中创建了一个软件包分支，但该软件是在另外的项目中被开发的。 osc branch openSUSE:Factory glib2
会创建home:$yourself:branches:GNOME:UNSTABLE/glib2.
这保证了你的修改延续了该软件包真正的”家“下已有的修改串流。
进行修改工作
现在你已经有了一个软件包分支，你可以在它之上开始工作了。下面的命令：
osc checkout home:$yourself:branches:openSUSE:Factory/initviocons cd home:$yourself:branches:openSUSE:Factory/initviocons
支取了该分支到你的本地文件系统。源链接被展开了。当你创建一个软件包分支时，创建的是一个到源软件包的链入而不是复制所有文件。通过这个链入，即使源做了修改，我们也能保持最新状态。但是在你的分支下工作时，你可能想要真正的软件包源文件，而不是一个_link XML文件。所以默认支取一个链入包的时候会展开这个链接给你源软件包的内容。因此你在支取过程中得到了源代码/源文件和任何已有的修改。
# 现在可以工作了： # 用vi编辑一些东西（...） vi ... # 查看开放式编译服务状态 osc status # 再写点东西 vi ... # 生成修改日志 osc vc
你的修改可以是新特性，代码修复，改进等等。
# 本地编译 osc build
本地编译能帮你减少开发时候的”左顾右盼“时间（等待代码上传、编译时无所事事）;每次你进行了一项修改时不需要等候开放式编译服务结束编译（或者编译失败）你的软件包。
一旦你编译完成，下面该通知开放式编译服务你已进行了修改：
# 提交修改，-m为附加消息 ”修改了这儿或者那儿“ osc commit -m "changed this and that"
你的修改会被上传到服务器，并且计划一次编译。
即使你支取了展开好的源文件，你也不要自己去为基础包制作补丁。开放式编译服务会处理好它们，通过自动比较你的分支和源软件包，它会在你的分支项目下自动创建补丁。
过一会儿你可以用下面命令查看你的修改是否全部通过编译：
# 检查它是否能编译 osc results
有时候你会想要看看你的分支和源软件包究竟有哪里不同。比如你可能想和其他人讨论你的修改，或者你只想看看其他开发者这段时间都干了什么。用这个命令：
# 显示你的版本和openSUE:Factory下面的版本（或者任何其他的源代码树）的不同 osc rdiff home:yourself:branches:openSUSE:Factory initviocons
编译调试
osc build 在编译文件夹下（默认为/var/tmp/build-root/abuild/rpmbuild/BUILD）下留下了一些文件以便于帮助你诊断问题。osc build的最后一行输出是：
The buildroot was: /var/tmp/build-root 编译文件夹是：/var/tmp/build-root
如果你去那里，并且乐意，你可以检查下面文件：
| 名称 | 意义 |
|---|---|
| .build.log | 检查编译过程并确认错误所在 |
| .build.command | 进行编译的参数 |
| .build.packages | 目标文件所在的目录 |
如果编译失败了，你可能会动心去”在编译文件夹下“修改点什么;这通常不是一个好想法，因为命令osc build一般会舍弃那里的任何东西（ rm -rf 删除）并从头再来。如果编译耗时很长——这对大项目来说是很正常不过的，这种策略很不幸对增量实时修改来说就是不可行的。想绕开这个问题，检视你的.build.command文件（在编译目录下哦）;它通常包含这样的一行：
rpmbuild -ba package.spec
这个命令会舍弃你已经编译了的任何东西，于是它本身也就没用了。可是，下面的命令却可以续传已有编译：
rpmbuild -bc --short-circuit package.spec #编译 rpmbuild -bi --short-circuit package.spec #安装
这些选项的细节可以在Fedora RPM指南中找到。
请求并回你的修改
一旦你自己满意了并且相信你的改动有很大可能会被上游项目的维护者（如果你用这份文档中的例子的话，就是openSUSE:Factory项目的维护者）采纳，你可以自管去提交一个并回请求。
osc submitrequest -m 'version update to 3.3'
这个操作会提交你在本地工作文件夹中对代码包的修改到源链接中指定的项目里去。
你也可以不检视本地工作文件夹直接用：
osc submitrequest home:$yourself:branches:openSUSE:Factory initviocons openSUSE:Factory -m 'version update to 3.3'
这将会创建一个请求标明你正在提供一些对工厂版来讲很”史诗级“的东西。(￣ε(#￣)☆((O==(￣▽￣)o 上游的维护者会尽快检视它。如果修改是可以接受的，他们会合并它到上游项目。如果它需要更多的优化，他们会回复你一些反馈。
我的申请是如何被处理的？
一个项目的维护者（比如openSUE:Factory）可以这样检查新申请
% osc request list openSUSE:Factory 37 new home:poeml/initviocons -> openSUSE:Factory/initviocons 'version update to 3.3' #ID STATUS FROM -> TO ‘MESSAGE’ #格式是： 编号 状态 从哪个分支项目来 -> 请求并回到哪个主项目 ‘附加消息’
维护者会通过比较它和源软件包来检视修改，并决定接受它、拒绝它并且给出拒绝原因。
% osc request show -d 37
Request to submit (id 37):
home:poeml/initviocons -> openSUSE:Factory/initviocons
Source revision MD5:
f839321325a0b5582def283c3520bf13
Message:
'version update to 3.3'
State: new 2008-03-20T19:57:02 poeml
changes files:
--------------
--- initviocons.changes
--- initviocons.changes
@@ -20 +20 @@
- which sends a characteristic primary da
+ which sends a characteristic primary DA
[...]
之后，维护者可以如此通过请求：
osc request accept 37
或者拒绝并附加理由：
osc request decline -m "没有修改日志，但大姐那是必须的。" 37
网页界面实例
这里描述了如何通过网页界面修改源代码，你可以在http://build.opensuse.org 找到针对openSUSE的。
网页界面可以很理想的得到概貌，或者修改点简单的东西，比如很明显的错误或者代码包的描述。想要做更多更复杂的修改，比如修复合并冲突，还是推荐用命令行客户端。
如何提交我的修改到他人的软件包？
假设你想要修改openSUSE:Factory/initviocons，并且稍后请求你的修改并回到openSUE:Factory项目。
下面内容一步步告诉你怎么做。
创建一个分支包
你需要创建一个分支，主要是源软件包的一个拷贝，因为你一般说来没有源软件包的写入权限。或者你想要在分发你的代码给全部用户前进行先期测试。
对源软件包的任何修改将被你的分支默认自动继承。
对于openSUSE:Factory去 软件包列表 找到你的软件包。
创建一个分支项目
首先，我们创建我们想要在我们的家项目下进行工作的软件包和它的母项目的分支。点击”Actions“菜单，之后点击”Branch package“。
服务器会在home:$yourself:branches这里创建一个新项目，即分支项目。分支项目有着和源项目相同的编译设定。这个命令同时也用源链接的形式在分支项目中创建了源软件包的链入。
很多包都有一个指定的”开发项目“。在这种通常情况下，服务器创建的是到开发项目而不是源项目的链接。具体解释见命令行实例。
进行修改
点击”Source Files“标签，并如意编辑你的源文件。你需要等待然后检视看它们是否能真正编译。
你可能也想要下载RPM包来测试你的修改在运行时是否真的能有质的飞跃。
请求你的修改被并回
一旦你对自己满意并且相信你的改动有很大可能被上游维护者（在这里是openSUSE:Factory的维护者）采纳，你可以自管去提交一个并回申请。
你既可以通过”Actions”菜单创建一个并回申请也可以使用“Source Files“页面下方的”显示不同并请求并回修改“链接。
这会创建一个对目标维护者的请求，他将复核你的修改，通常情况下接受它。你的分支包通常在并回操作后被删除（除非你拒绝这么做）。
针对openSUSE:Factory工厂版的特殊处理
openSUSE:Factory下的每一个包都有一个”开发源“。这些开发源被用于软件包自身的开发。（你可以”看到“一个软件包的开发源，通过 osc meta pkg openSUSE:Factory <软件包名称> | grep devel。）如果你想要修改一个在openSUSE:Factory中的软件包，使用
osc branch openSUSE:Factory <package>
后发现你从其他地方得到了这个包，请不要大惊小怪。
osc sr -m "- updated package, thanks to foo bar" <devel:project> <package> openSUSE:Factory
想要提交一个到openSUSE工厂版的归并请求（注意：开发源维护者接受你的并回请求不会自动触发到工厂版的归并请求！），开发源的维护者（通常是你自己）必须做类似下面的操作：
osc sr -m "- 软件更新，感谢CCAV“ <开发源名称> <软件包名称> openSUSE:Factory
所以我们有如下两种情况：
分支的，非官方的开发源维护者的工作流程
- osc branch openSUSE:Factory <软件包名>
- osc submitrequest (向开发源提出并回请求)
- 开发源维护者通过 osc sr accept <id> 接受请求
- 开发源维护者提出到工厂版的归并请求
- 自动化编译组的官方人员通过请求
开发源维护者的工作流程
- 开发源维护者提出到工厂版的归并请求
- 自动化编译组的官方人员通过请求
osc request list <devel:project>
来检查针对他们源的归并请求，是个不错的主意。