openSUSE:Factory 评审

Factory 开发

openSUSE 评审团队的评审

我们基本上希望确保打包遵循 Portal:Packaging 中已捕获的最佳实践，并遵循团队已建立的高级别准则。

强制执行一些流程问题

每次提交都必须有一个 changes 文件条目。
对于更新提交，changes 文件应引用一个或多个错误报告或 FATE 条目。
对于新版本提交，应包含对新版本更新中包含/更改内容的合理引用。（另请参阅：（不）引用上游日志）
更改必须按时间顺序排列。（自动检查）
如果对旧条目进行更改，则只应修复错误编号或拼写错误等问题。旧条目通常不应删除或实质性更改。
必须严格遵守更改日志标题格式，例如用户、日期、时间以及 '----' 字符串的格式。
软件包的新更改日志条目应与以前的条目保持一致。
任何给定补丁文件的添加都需要在 .changes 文件中提及。（自动检查）补丁文件应附有文档，例如以 [openSUSE:Packaging_Patches_guidelines 补丁内描述] 的形式（手动检查）。
任何给定补丁文件的删除都需要在.changes文件中提及（自动检查），即使删除仅仅是因为上游接受了该补丁。

检查“ExclusiveArch 标签”的使用。一般来说，软件包应该为所有架构构建，但如果完全没有意义，则应在 spec 文件中作为注释提及。
确保遵循所有标准打包最佳实践 openSUSE:Packaging_Patches_guidelines。例如
- 减少或消除源代码中关于补丁的警告
验证许可证头
前言必须包含基本标签集，例如：名称、版本、发行版、URL 等。
检查版本以确保其合理且可升级
查找 specfile 中不应再出现的内容，例如
- AutoReqProv: on, # norootforbuild, # usedforbuild, %clean部分等。
查找 specfile 中应替换的内容，例如
- %{?jobs:-j%jobs}→%{?_smp_mflags}
- %fdupes %buildroot→%fdupes %buildroot/%_prefix（否则可能会在顶层目录和分区之间出现硬链接，导致安装失败）
查找正确的 OBSOLETES（参见 openSUSE:Package_dependencies）
确保正确的软件包命名，例如共享库的打包，避免使用冒号等。

所有违规行为是否都应立即导致软件包被拒绝？大部分情况下是“否”。需要一些常识，但有时我们团队的成员对如何处理违规行为有不同的看法。这需要（随着时间和耐心）进行完善和协调。

解决违规行为的一些方法

拒绝提交。这可能看起来很苛刻，但通常只意味着“需要更多工作”。如果一个软件包被证明是无望的（例如因为专利），我们将告知提交者不要再尝试。
创建自己的分支，自己进行小更改，然后重新提交/废弃
通过 OBS 评论系统或任何其他方式向提交者发送消息。（沟通总是好事，通常也受到打包者的欢迎）。始终解释您做了什么以及您现在期望做什么。要求提交者纠正违规行为。

新的 setuid 二进制文件等需要首先由安全团队进行评审。将 security-team 添加到评审队列中，以便他们可以检查。目前只能通过命令行完成。

   osc review add -G security-team ID

一般来说，安全评审具有最高优先级，我们可能会过于谨慎。

对于维护包，patch-info 文件的评审是正常评审之外的额外步骤

确认 patchinfo 数据与源代码中的更改匹配，反之亦然。
验证 patchinfo 中列出的错误编号和 CVE 引用与更改日志中列出的错误编号匹配，反之亦然。（如果使用正确的缩写，则有些自动化）。
所有更改都必须在行为和 ABI 上向后兼容。这意味着默认值不能作为更新的一部分悄悄更改，配置或包的主要功能不能拆分到其他部分或类似情况。共享库更改必须在不进行完全重新构建的情况下，考虑到它们对产品的影响进行评审。
所有提交都应具有一致的软件包命名（扩展软件包名称，即 foo.openSUSE_X.Y）并具有指向 openSUSE_X.Y:Update 的源链接。这对于版本号跟踪的正确工作是必需的，即使是新软件包也需要。
检查是否至少给出了一个 bugzilla 引用。bugzilla 错误应提供更新所需的额外原因。

这些是我们总是会拒绝提交的原因

openSUSE 评审团队对一般更改遵循“尽力而为”的方法，可能会出错——有时过于谨慎，特别是对于安全问题，有时为了尽快发布构建而接受一些东西。

此外，维护评审可能会强制执行更严格的规则。

团队也可能接受软件包并创建错误报告以便稍后清理软件包。

删除请求必须满足以下最低要求

提供了有效理由，并事先在公共 openSUSE 邮件列表上进行了讨论（并非总是如此）
- 该软件包没有活跃的维护者
- 上游开发已中止，维护负担（修补安全漏洞、错误等）不值得付出努力
它可能是软件包重命名的一部分（即，有一个新的提交请求，包含相同名称但不同名称的软件包）
- 删除请求应提及其他提交请求编号，并且两者应一起进行评审

Perl 包应使用自动化工具 _cpanspec_ 生成。这可确保最大限度的兼容性，并几乎保证评审成功。您可以向 *coolo* 询问此脚本。

Ruby 包应使用自动化工具 _gem2rpm-opensuse_ 生成。这可确保最大限度的兼容性，并几乎保证评审成功。您可以向 *darix* 询问此脚本。