openSUSE:构建服务协作
简介
开放构建服务提供了不同的协作方式。最简单的方法是授予更多人员在软件包或项目中的写入权限。这种方式允许一个小型紧密合作的团队快速协作。
但是，这种方法在许多情况下行不通
- 未知的贡献者没有写入权限，因此无法提交更改。
- 项目信任度随着拥有写入权限的人数增加而降低。
- 即使拥有写入权限的人也可能希望在参与项目之前对其更改进行审查。
- 大型项目中的持续更改导致项目永远无法完成构建的情况。基本软件包的更改可能会无限期地阻止其他软件包。
因此，开放构建服务提供了另一种贡献方式。您可以在分支项目中准备更改，然后请求将更改合并回去。
大型项目，例如 KDE、GNOME、Apache 和 YaST，通常需要另一层审查，可以在提交到主项目之前对提交进行分阶段处理。例如，openSUSE:Factory 就是这种情况。该项目为每个软件包定义了一个开发项目。开放构建服务帮助用户针对这些项目进行开发并提交贡献。开发项目的项目所有者然后可以将所有贡献提交到 openSUSE:Factory。这个过程在 这些幻灯片中可视化。
使用 CLI 的示例
如何将我的更改贡献给其他人的软件包？
假设您想使用 openSUSE:Factory/initviocons，并在以后将您的工作提交回 openSUSE:Factory 项目。
以下内容将逐步向您展示该操作。
创建分支软件包
首先，我们在我们的主项目中创建一个我们想要处理的软件包的分支。
# osc branch <source project> <source package> osc branch openSUSE:Factory initviocons
如果它不存在，此命令首先在 home:$yourself: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
将软件包签出到您的本地文件系统。源链接是扩展的。当您分支一个软件包时，会创建指向原始链接的链接，而不是复制所有内容。使用此链接，我们的分支在原始更改时保持最新。为了对您的分支进行工作，您需要拥有原始源/文件，而不是一个 _链接 XML 文件。因此，默认情况下，签出链接的软件包会将链接扩展到原始软件包的内容。因此，您获得了原始源/文件以及签出中的任何现有更改。
现在准备您的更改。如果源文件不在 .tar.gz 归档文件中，只需编辑文件
vim <path/to/file> ... osc diff ...
如果源文件在 .tar.gz 归档文件中，您需要做一些不同的操作。使用以下命令准备您的补丁quilt(使用以下命令安装它sudo zypper install quilt):
# Unpack the .tar.gz archive quilt setup <name of package>.spec cd <name of package-version number> # Create a patch file to hold your changes quilt new <desired name of your patch>.patch # Edit the files # Option 1: quilt edit <path/to/file> # Option 2: quilt add <path/to/file> <edit the file in the graphical editor of your choice> # Give your patch a clear description quilt header -e # Complete the patch file once you're done editing everything quilt refresh # Integrate your patch into the package cp patches/<name of your patch>.patch .. cd .. /usr/lib/build/spec_add_patch <name of your patch>.patch # Add your patch to the repo osc add <name of your patch>.patch
现在，请使用此格式为您的更改提供清晰的描述，并提及错误："(bsc#<错误编号>)"
osc vc
进行本地测试构建，以确保一切正常
osc build
本地构建有助于缩短开发期间的周转时间；您无需等待开放构建服务完成构建（或构建失败）您的软件包每次您进行更改。
一旦您的更改软件包在本地构建，就可以通知开放构建服务您的更改
# commit the changes osc commit -m "changed this and that"
您的更改将发送到服务器，并安排构建。
即使您签出了扩展的源，您也不需要自己创建相对于基本软件包的补丁。开放构建服务会处理所有这些，通过比较您的分支和原始分支并创建开放构建服务上的补丁（未扩展）。
一段时间后，您可以使用以下命令查看是否一切正常
# check whether it builds osc results
有时您想查看您的工作与原始软件包的不同之处。例如，您可能想与其他人讨论您的更改，或者您可能只是想看看其他开发人员同时在做什么。为此，请使用
# show differences between your version and the one in openSUSE:Factory osc rdiff home:yourself:branches:openSUSE:Factory initviocons
调试构建
osc build在构建目录中留下一些可以帮助您诊断问题的文件。由以下命令输出的最后一个语句osc build是
The buildroot was: /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 #compile rpmbuild -bi --short-circuit package.spec #install
这些选项在 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'
这将创建一个请求，表明您正在为 Factory 提出一些绝妙的想法。:-) 项目的维护者会快速检查它。如果更改可以接受，他们可以将其合并到他们的项目中。如果需要更多工作，他们可以向您发送更多反馈。
我的贡献如何处理？
项目的维护者（例如 openSUSE:Factory）应该检查贡献（即提交请求），如下所示
% osc request list openSUSE:Factory 37 new home:poeml/initviocons -> openSUSE:Factory/initviocons 'version update to 3.3'
维护者将通过将其与当前软件包源进行比较来查看更改，并接受或拒绝更改并给出理由。
% 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 "changelog missing, but required by policy" 37
使用 Web 界面
这描述了如何通过 Web 界面 更改源。
WebUI 很好地了解概况并更改简单的事情，例如明显的错误或软件包描述。对于进行更复杂的更改，例如解决合并冲突，建议使用 osc。
如何将我的更改贡献给其他人的软件包？
假设您想使用 openSUSE:Factory/initviocons，并在以后将您的工作提交回 openSUSE:Factory 项目。
以下内容将逐步向您展示该操作。
创建分支软件包
您需要创建一个分支，这基本上是原始软件包的副本，因为您通常没有写入目标权限。或者您想先进行实验，然后再将您的代码发送给所有用户。
分支默认情况下与分支软件包的更改合并。
对于 openSUSE:Factory，请转到 软件包列表 并找到您的软件包。
创建分支项目
首先，我们在我们的主项目中创建一个我们想要处理的软件包的分支。单击“操作”菜单，然后单击“分支软件包”。
服务器将在 home:$yourself:branches 下创建一个新的项目，分支项目。此分支项目具有与原始源项目相同的构建设置。该命令还在分支中将软件包创建为源链接。
许多软件包都定义了“开发项目”。在这种常见情况下，服务器将创建指向该开发项目的链接，而不是源项目。
处理更改
单击“源文件”选项卡并根据需要编辑您的源。您应该等待并查看它们是否真的构建。
您可能还想下载软件包并尝试您的更改是否真的在运行时有所不同。
提交您的更改以进行合并
一旦您满意并相信您的更改有很好的机会被上游项目的维护者接受——也就是说，如果您使用本文档中的其他示例，则被 openSUSE:Factory 项目的维护者接受——您可以继续请求提交。
您可以选择通过“操作”菜单创建提交请求，也可以在“源文件”页面上找到“显示差异并提交这些更改”的链接。
这将为目标作者创建一个请求，他们将审查您的更改并通常接受它。您的分支软件包通常在合并后会被删除（除非您拒绝了）。
openSUSE:Factory 的特殊处理
openSUSE:Factory 中的每个软件包都有一个“开发存储库”。这些开发存储库用于软件包本身的开发。（您可以通过 osc meta pkg openSUSE:Factory <package> | grep devel 或更简单地使用 osc dp openSUSE:Factory <package> “看到”软件包的 develproject。）如果您执行 osc branch openSUSE:Factory <package>，如果您想更改 openSUSE:Factory 中的软件包，请不要惊讶于从另一个位置获取软件包。
要向 openSUSE Factory 提交请求（注意：接受开发项目中的提交请求不会自动触发 Factory 的提交请求！），开发项目的维护者必须执行以下操作
osc sr -m "- updated package, thanks to foo bar" <devel:project> <package> openSUSE:Factory
因此，我们在这里有两个场景
分支、非官方开发项目维护者的工作流程
- osc branch openSUSE:Factory <package>
- osc submitrequest（将提交请求发送到 devel 项目）
- Devel-Project 维护者通过 osc sr accept <id> 接受
- Devel-Project 维护者创建针对 Factory 的新提交请求
- 自动构建人员接受更改
开发项目维护者的工作流程
- Devel-Project 维护者创建针对 Factory 的新提交请求
- 自动构建（openSUSE:Factory 团队）人员接受更改
osc request list <devel:project>