openSUSE:Factory dos and donts
目录
维护者应当 ...
... 始终认为其他人将接手该软件包维护
一条可能是最为重要的规则：对一个软件包的任何操作都应当能轻松地被其他任何想要给予帮助的潜在贡献者所理解。
为此我们需要在包括变更日志 .changes 文件、构建规则 .spec 文件的注释中提供良好的文档说明，也应该包括各种相关资源的链接（对于补丁，可参见补丁指南）。
这同时也意味着我们应当避免意义不明的快速修复。
... 及时、友好地响应提交请求
一个好的维护者应当确保贡献者能得到激励，一个好的方法是及时且友好地响应提交请求（持续数天没有任何响应的等待实在是劝退）。对于不合适的请求，应当解释清楚具体原因而不是直接拒绝掉。更多 OBS 请求检查相关内容可参见对应英文维基
... 将任何变更记录在变更日志文件
每次你要提交修复或者更新到工厂版（Factory），你都需要记录你的所有变更到 .changes 文件（即使不推到工厂版也推荐如此）。你可以使用 osc vc 来辅助你插入一条变更模板。
一条好的变更日志不应该简单地描述变更本身，还应该对变更做出解释。比如“Add pkgconfig(coolstuff) BuildRequires”就纯粹是描述性文字，可以使用“Add pkgconfig($coolstuff) BuildRequires to enable $cool feature”来简要概述该变更为什么重要。
同样不要忘了引用变更解决的问题（bug entries）和特性请求（feature requests）。如 “Fix bnc#12345” of “Close fate#12345”
... 使用 %{optflags}
确保 %{optflags}（或者 $RPM_OPT_FLAGS ）作为 CFLAGS/CXXFLAGS 有被传递给 C/C++ 编译器。使用 %configure 宏大概能办到，但某些情况在使用 make 前使用 export CFLAGS="%{optflags}" 是有必要的，比如一些需要打补丁的情况。
... 关注 rpmlint 警告
在软件包构建的最后阶段，rpmlint 被用来分析生成的软件包，检查常见打包错误。检查结果在构建日志的最后，以 RPMLINT report: 所在行开始。修复这些警告通常能提升软件包的质量。
... 遵循 FHS 标准
将软件包的所有文件放在正确的地方，遵循 文件系统层次结构标准。通常，得到良好维护的上游项目会帮你完成这件事当你使用 %make_install（或 make install）的时候。
... 使用一个固定的打包风格
得到同样的构建结果的规则 .spec 文件可以有多种不同的写法，所以遵循一个固定的打包风格来降低可能对贡献者的影响是必要的。
可以使用 spec-cleaner 命令行工具来格式化 .spec 文件到一个易读的打包风格。比如它会将构建依赖（BuildRequires）格式化到每行一个（虽然你一行想放多少都行）来使得提交请求后方便使用 diff 看出改动。
... 阅读对应的文档
阅读 打包指引 中和你的包相关的部分。
维护者不应当 ...
... 在软件包中打包捆绑库
只要有可能，应尽量使用系统库而不是捆绑的库。向上游项目提bug或提交补丁解决。 我们希望每个软件都能使用共享库，而不是使用自己捆绑的版本。
... 在还有未处理提交请求时做出变动
在你更新或者修复软件包之前，看看你的提交请求列表。其他人可能已经作出了对应改动，如果置之不理闷头重做是相当打击贡献者积极性的。
... 为自己保留补丁
如果你为自己维护的软件包打了补丁来修复些什么，你应当向上游项目报告并提交对应补丁。这样你就不需要在上游更新之后再更新补丁，并且上游项目的其他使用者也会因为你的补丁而受益。