openSUSE:Autobuild review
目录
自动编译团队复审
我们基本想要确保打包遵照 Portal:Packaging 中已归纳的最佳实践，并遵守我们团队建立的 高级别指南。
一般复审
这些是一些强制的流程性问题：
- 软件包能够在所有支持架构(目前是 x86 and x86-64)上编译吗？该检查通过自动脚本完成。
- 软件包提交自它的开发源吗？该检查通过自动脚本完成。
修订日志复审
- 每次更新必须有一条修订日志。
- 作为维护更新的提交，修订日志必须包含一个或多个 bug 的引用或者需求特性的引用。
- 作为版本升级的提交，必须说明其包含/修改的重要内容。
- 修订日志必须按时间排序。
- 若是修改旧条目，则只能修复 bug 编号或书写错误。旧条目一般不应删除或实质性改动。
- 修订日志头部格式必须正确，像 user, date, time, 和 '----' 字符串都必须要有。
- 新修订日志条目应和之前的条目连贯。
完美实例： KDE:Extra hotot
Spec 文件复审
- 检查有无使用 'ExclusiveArch 标签：通常软件包应针对所有架构编译，但如果这样完全就没意义，请在注释中说明。
- 确保遵守了openSUSE:Packaging_Patches_guidelines中提到的全部标准打包最佳实践，例如：
- 是否减少或根除了源代码中补丁的警告
- 校验版权头部
- 开头是否使用了基础标签集，如：name, version, release, URL,等等。
- 合理插入 %{version} 以保证 spec 文件合理、可升级。
- 查找不再应该在 spec 文件中的代码如: AutoReqProv: on, #norootforbuild, #usedforbuild,等等。
- 查找合适的 OBSOLETES (详见 openSUSE:Package_dependencies)
- 确保合适的软件包命名，比如共享库打包，避免冒号，等等。
接受或拒绝
所有的违规都会立即导致软件包被拒绝吗？大多数时候并非如此。有时一些共识性的看法会占上风，但有时候我们团队的成员也对如何处理违规有不同的看法。这需要完善和协调 (需要一些时间和耐心）。
一些处理违规的方法：
- 拒绝提交 (有时的确显得有些刻薄)，但这通常意味着还有很多很多的东西要做。同时，如果一个软件包的修改已经没有任何意义(比如专利问题)，我们也会劝说提交者放弃这一修改。
- 创建我们自己的分支，自己来做这个修改，然后重新提交
- 发信给提交者(沟通总是被鼓励的，提交者也易于接受这种方式)。通常可以清楚地说出为什么你会这样做，你已经完成了什么，你希望希望别人继续做什么，并要求提交者更改他违反的东西。
安全复审
新的预设执行用户的可执行文件等等。需要先由安全团队复审。
通常，安全复审有最高优先级，当然，我们承认太谨慎有时也会出错。
硬性拒绝
我们总是会拒绝这样的提交申请
- 编译失败
- 缺失 spec 文件, 源代码, 或修订日志
- 没有新修订日志条目
- rpmlint 报错。有时也拒绝有大量警告的软件包。
- 修订日志条目惨不忍睹，缺少需要的数据
- 比如预设执行用户或者明显安全违规这类可疑的东西。rpmlint 通常都能找到这些，但我们也会手工找，并且拒绝这样的申请。
- 头文件被放在了错误的软件包中，或者其他明显违反打包策略的东西。(有很多例外情况，但随着时间这类例外越来越少了。)
- 用错了辅助宏
- 之前纠正过错误重复出现。
最大努力
复审团队尽最大努力来工作，有时也会出错，有时是因为太谨慎，尤其是安全问题，有时是太急。
维护复审可能强制使用更严格的规则。
该团队也可能刚接受软件包就发 bug 报告要求清理该包。
删除请求的复审
删除请求至少需要满足以下要求：
- 提供了一个合理的理由，该理由已事先在一个公共邮件列表里讨论过 (不总这样)
- 软件包没有积极的维护者
- 上游开发停止，维护负担(补缀安全漏洞，除虫，等等)付出的和得到的不成比例
- 可能是软件包重命名的一部分 (例如同时有一个同样的但不同名的包的新提交请求)
- 删除请求请提及其他提交申请编号，两者会一起接受复审
软件包类型指南
共享和静态库
Perl 软件包
Perl 软件包应由自动工具 _cpanspec_ 生成。这确保了最大化的兼容性，一般都能得到成功的复审。此工具的问题可以询问 *coolo*。
http://en.opensuse.org/openSUSE:Packaging_Perl
Python 软件包
Ruby 软件包
Ruby 软件包应由自动工具 _gem2rpm-opensuse_ 生成。这确保了最大化的兼容性，一般都能得到成功的复审。此工具的问题可以询问 *darix*。