openSUSE:OpenSUSE 发行版架构策略

请在编辑此页面之前，在适当的分发邮件列表中或 opensuse-project 列表中讨论更改。

版本：20201124

什么是 openSUSE 分发的主要架构？

在此策略之前，openSUSE Tumbleweed 分发的主要架构（即开发、测试和发布所针对的架构）是 i586 和 x86_64。对于 openSUSE Leap 分发，主要架构一直是 x86_64。

本文档描述了 openSUSE 分发架构被声明为主要架构所承担的责任。openSUSE 分发的主要架构是指一起开发、测试和发布并承载主要分发名称的架构。

鼓励移植到其他架构，并尽可能处理其需求，但这些端口需要清楚地记录它是相应 openSUSE 分发的架构移植。

任何希望成为主要架构的 openSUSE 架构移植都必须遵守以下准则。这是该准则的最低规则集。还可以定义特定于分发的其他策略。

任何主要架构的提名都应在相应的 openSUSE 分发邮件列表中提出讨论，并宣布在 opensuse-project@ 邮件列表中。

openSUSE 包含并欢迎其他架构移植，并倾向于平等地平衡任何其他架构的需求。在附加架构的基础上，每个 openSUSE 分发都可以定义一组主要架构。

为了使架构成为主要架构，必须满足以下要求

有一组活跃的定期贡献者关心分发构建，并且可以通过一个通用的邮件列表联系到他们，以解决架构特定的缺陷（“架构团队”）。该架构团队为该架构贡献并共同维护 openQA 测试自动化。至少有一名成员参加每周 openSUSE 发布团队会议。

可以完全从经过审查的源代码构建分发的完整 Bootstrap，从一组受信任的二进制文件开始。发布到用户分发的任何源代码都经过 openSUSE 审查团队的同行评审。

分发维护者会在 https://bugzilla.opensuse.org/ 上为软件包维护者提交错误报告，如果他们在架构移植中发现问题。软件包维护者承诺谨慎处理主要架构，并在提交更改之前在开发项目中进行测试构建。软件包维护者承诺快速处理回归，并通常接受该平台的错误报告并致力于解决问题。

架构团队始终专注于保持每个软件包的可重构性。在任何时候，无法从源代码构建的软件包不应超过 5%，并且分发的核心软件包（例如，今天定义为 Ring-0）应始终能够成功地重新构建并传递其构建定义的测试套件。主要架构上的提交构建失败是拒绝提交的有效理由。

分发的 Tumbleweed 版本定期发布新的快照（至少每月一次）。openSUSE 发布仅在通过定义的 openQA 测试后发布，这为用户提供了他们期望的主要架构的稳定性要求。

分发的 Tumbleweed 版本采取适当措施，以确保 Ring 0 和 Ring 1 软件包可以随时从源代码构建。例如，可以通过确保没有软件包源代码进入会使 Rings 的大部分内容失败，或者可以通过回滚有问题更改直到问题得到解决来实现。

Tumbleweed 分发是从经过 openSUSE 审查团队审查的 openSUSE Factory 源代码集构建的。不允许永久覆盖或偏差。在平台上发生严重回归的情况下，在解决回归问题之前，可以允许临时覆盖（例如：最新的 Factory kernel-source 在该架构上无法启动。在这种情况下，暂时恢复到较旧的先前发布的源代码是可以接受的）。这里的意图是解耦各个架构发布流程，但不是允许任何长期偏差。主要架构应在任何时候都保持一致的体验和软件版本。

答：截至 2020/06，我们的 openQA.openSUSE.org 测试 x86_64（142 个测试通过）、AArch64（81 个测试通过）、PowerPC（32 个测试通过）和 s390x（0 个测试通过）。这使得 AArch64 迄今为止是这方面的最合适的候选者。

注意：请参考 https://en.opensuse.net.cn/openSUSE:Submitting_bug_reports 而不是仅仅使用 bugzilla url，wiki 页面包含更多信息。https://bugs.opensuse.org 可以用作简写。

目前社区尚未对此建立明确的准则。但是，常见做法更侧重于“核心”软件包集（在 x86_64 上，这由 DVD 媒体集定义），而不是叶软件包。主要架构定义此“核心”软件包集。

任何主要架构都应努力获得分发认为需要持续通过的越来越多的 openQA 测试。