openSUSE:Factory dos and donts
维护者应该...
...记住其他人也会处理这个软件包
这可能是最重要的规则：在软件包中所做的一切都应该易于被任何前来帮助的人理解。
这包括良好的文档，既在.changes文件中，也在.spec文件中的注释中，还包括指向相关资源的链接（对于补丁，使用 补丁标签）。
这也意味着应该避免神秘且快速的修复。
...及时且友好地回复提交请求
一个好的维护者会确保贡献者保持积极性。实现这一点的最好方法是及时（等待几天以上没有反馈会让人失去动力）且友好地回复提交请求。不要以生硬的方式拒绝请求，而是尝试清楚地解释您对提交的疑虑。构建服务的 审查功能可以在这方面提供帮助。
...在更改文件中记录每一次更改
每次您提交修复程序或更新到 Factory 时，都必须在.changes文件中记录所有更改。您可以使用osc vc来帮助您创建新的.changes条目的模板。
一个好的.changes条目不仅描述了更改，还解释了为什么需要这些更改。例如：“添加 pkgconfig(coolstuff) BuildRequires”纯粹是描述性的，而“添加 pkgconfig($coolstuff) BuildRequires 以启用 $cool 功能”可以快速概述更改的重要性。
此外，不要忘记引用由于更改而关闭的错误条目或功能请求。“修复 bnc#12345”或“关闭 fate#12345”可用于此目的。
...使用 %{optflags}
确保%{optflags}（或$RPM_OPT_FLAGS) 作为 CFLAGS/CXXFLAGS 传递给 C/C++ 编译器。使用%configure可能会有所帮助，但有时使用export CFLAGS="%{optflags}"在运行make之前是必要的。有时也需要进行补丁。
...查看 rpmlint 警告
在构建结束时，rpmlint 用于分析构建的软件包并警告常见的打包错误。报告位于构建日志的末尾，并在RPMLINT 报告行之后。修复这些警告通常可以改进软件包。
...遵循 FHS
将所有文件放在软件包中的正确位置。尊重 文件系统层次结构标准。通常，维护良好的上游项目会在您使用%make_install（或make install).
...使用一致的打包风格
A.spec文件可以用多种方式编写以达到相同的结果，因此采用特定的打包风格以降低贡献者的工作量会很好。
spec-cleaner 工具（可在 openSUSE:Tools 中找到）可以更新.spec文件以使用易于阅读的打包风格。例如，它每行只放置一个 BuildRequires 依赖项（尽管您可以放置任意数量的依赖项），因为这样可以更轻松地查看提交请求中的更改。
...阅读相应的文档
阅读与您的软件包相关的 打包指南。
维护者不应该...
...包含捆绑的库
尽可能尝试使用系统库而不是捆绑的库。向上游报告错误，创建补丁。我们希望每个人都使用共享库，而不是携带自己的版本。
...在有任何未处理的提交请求时进行更改
如果您正在更新/修复软件包，请先简要查看您的提交请求队列。可能其他人已经完成了。如果只是破坏它并重新做一遍，他们会非常沮丧。
...保留补丁供自己使用
如果您必须修复某些内容并修补您正在打包的软件，请不要将补丁仅保留给自己。将其放入上游错误跟踪器中。与上游沟通。如果您这样做，当上游创建新版本时，您就不需要移植它，其他人也可以从您的补丁中受益。