GLEP 40：跨所有架构标准化“arch”关键字。

状态

经 Gentoo 理事会于 2005 年 9 月 15 日批准。截至 2006 年 9 月 3 日，我们拥有一个强大的 x86 架构团队，因此此 GLEP 为最终版。

致谢

此 GLEP 起源于 gentoo-dev 上关于合并 x86 和 amd64 关键字的颇具争议性的讨论 [1]。此 GLEP 试图触及该不满情绪的核心。所提出的稳定关键字指南直接摘自 [2]。

摘要

是时候让 x86 不再成为标准关键字指南的例外了。因此，x86 架构团队应负责将软件包从 ~x86 移动到 x86。

动机

最初的非正式 x86 关键字策略，几乎任何使用某个软件包的 x86 开发人员（占绝大多数开发人员）都可以将其标记为稳定，源于 Gentoo 开发人员相对较少的时期。向树中添加软件包是主要关注点，而不是维护现有软件包。QA 考虑因素此后略微修改了该策略，现在应该是软件包维护人员标记 x86 软件包为稳定。当然，该策略假设软件包维护人员通常是 x86 开发人员，这种情况正在慢慢变得越来越不准确。

这种针对 x86 的策略与其他所有架构标记软件包稳定的方式截然不同。对于非 x86 架构，每个架构都有一个特定的“架构团队”负责将软件包从~arch移动到arch，虽然 vapier 指出“架构团队通常会听从维护人员（理所当然）关于何时应该将新版本标记为稳定的意见”。这种方法对于非 x86 架构非常有效，此 GLEP 断言，相同的方案也将有利于 x86。

规范

基本原理

建立一个强大的 x86 架构团队将涉及相当大的一次性成本——需要招募大量人员（amd64 架构团队有 19 名活跃开发人员和 12 名活跃非开发人员架构测试人员）来加入新架构团队，而说服开发人员以新方式工作可能更难。当然，各个架构之间一致性的好处是显而易见的，但这是否值得付出相应的成本？以下是有力论证的理由

• 随着时间的推移，随着 64 位系统成为主流，x86 可能成为一个次要架构。当前系统背后的隐含假设（大多数开发人员、用户和软件包维护人员使用 x86）将变得越来越不成立。
• x86 的 QA 显著改善。假设作者自己的行为具有代表性，大多数 x86 开发人员运行~x86系统。因此，开发人员是优秀的x86测试人员的假设实际上并不成立。一个明显的后果是，软件包往往会在~x86中停留很长时间，因为运行~x86的 x86 开发人员几乎没有理由注意到某个软件包没有被标记为稳定。然而，更重大的影响是，x86软件包很少在完整的x86树的上下文中被标记为稳定，因此，稳定的系统（不仅仅是稳定的软件包）的整体图景就丢失了。这种在完整的稳定arch树的上下文中标记为稳定的方案，据称 [3]，是非 x86 架构的 QA 明显优于 x86 架构的根本原因。

实现

创建强大的 x86 团队已经开始。更重要的步骤是正式改变策略，并持续努力说服现有 x86 开发人员接受这种改变。

替代方案

Stuart [4] 建议创建一个新的架构关键字：“[-]maint”，它将与正常的架构关键字并存，从而明确软件包维护人员的意图。Ciaranm 回复说，根据定义，位于~arch中的软件包是arch的候选软件包，因此软件包仅仅存在于树中（不在package.mask中）应该表明软件包维护人员的意图。关于这个想法应该使用“maint”关键字，还是其他名称，或者完全不同的变量，等等，进行了一番讨论，但基本内容没有太大改变。

Jstubbs 指出，如果所有非架构开发人员都在覆盖层中工作，这将是一个非常好的主意，但需要新的 portage（gensync）支持才能真正实现它。Stuart 指出，php5 的支持就是以这种方式处理的。作者认为，这种方法将使“位于~arch中意味着它是arch的候选软件包”的解释更加有效。

Ciaranm 和 weeve 指出，架构团队有时需要在软件包稳定方面覆盖软件包维护人员。Stuart 坚持认为，在这种情况下，架构团队应该愿意承担该软件包的支持负担。

向后兼容性

这里不是什么大问题。

版权

本作品根据 Creative Commons Attribution-ShareAlike 3.0 Unported 许可证授权使用。要查看此许可证的副本，请访问 https://creativecommons.org/licenses/by-sa/3.0/。