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*。