Rust 介绍规范团队进展，安排人员创建及维护“权威开发资源”
发布时间：2023-11-20 10:53:57来源：
IT之家 11 月 20 日消息，Rust 团队宣布在几个月前接受 RFC 3355 的提议，决定开始制定 Rust 语言的官方规范。
官方表示，在这一过程中，Eric（Rust 参考的维护者），Felix（Rust 语言团队），Joel（Rust 基金会）和 Mara（RFC 的作者）组建了“规范团队”，共同努力推动相关工作。
日前该规范团队发文介绍了这项工作的进展，以及后续的一些其他规划，并宣布将在未来为团队制定定期会议时间表、确定利益相关者名单，并制作首个 Demo 产品，IT之家整理相关内容如下：
编辑者方面（Editor）
作为 RFC 中规定的 “editor” 角色，由于基金会寻求该职位的理想人选时，一名候选人的提议最终被拒绝，基金会最终选择考虑内部选项作为替代方案。
基金会的技术总监 Joel 表示愿意担任该职位作为他现有工作的一部分。由于 Joel 在行业标准和技术编辑方面拥有丰富的经验，以及与 Rust 项目的密切关系，Eric，Felix 和 Mara 迅速同意让 Joel 担任规范编辑的职位。
规范团队方面（Specification Team）
官方表示，由于编辑者无法独自完成工作，因此他们组建了规范团队，作为语言团队的子团队。
其中成员包含：
Felix Klock（团队负责人）
Mara Bos（团队负责人）
Joel Marcey（团队成员，编辑者）
Eric Huss（团队成员）
利益相关者（Stakeholders）
官方宣称，他们将选择并维护一份有关“利益相关方”的列表清单，其中包括“专家”和“规范的使用者”，他们将作为顾问和审阅者。
其中成员包含：
Rust 语言团队的所有成员
一名或多名来自类型团队的代表
一名或多名来自操作语义团队的代表
一名或多名来自 Ferrocene（高保障 / 可用性，例如汽车行业）的代表
一名或多名来自形式方法研究与开发的代表
一名或多名来自操作系统开发（Rust for Linux; Microsoft）的代表
权限和审批（Authority and Approval）
虽然规范团队负责撰写和编辑规范，但对 Rust 语言的定义的权威仍由相关团队，如语言团队和库 API 团队等负责。这些团队在必要时应涉及其他团队 / 子团队，例如通过提出问题，提名问题进行讨论，并在关键决策上请求 FCP 批准。
官方表示，为了让规范团队能够在不受审批流程限制的情况下生成内容并进行迭代，他们将在工作存储库中制定一份规范草案，从而公开跟踪仍然需要团队批准的项目以及利益相关方提出的问题。
我们将所有变更分类为次要变更或重大变更。较小的更改是对规范团队来说似乎没有争议或微不足道的项目。例如，语言团队已经通过 FCP 批准的更改、排版和语法修复、初衷明确的澄清，以及类似的令人兴奋的更改。重大变更是那些可能有问题、重要或有争议的变更。规范团队和相关权威团队的任何成员以及任何规范利益相关者都可以将更改标记为重大更改。对规范的重大更改必须经过通常的批准流程（例如语言 FCP）才能出现在规范的已发布（非草案）版本中。
其中语言和规范团队应努力至少有一个共享成员（例如 Felix），充当联络员，以确保官方对“什么是次要更改”和“什么是主要更改”的理解保持同步。
目标
规范团队的目标是创建和维护 Rust 规范。
Rust 规范的目的是为确定哪些源文本是有效的 Rust 程序以及这些程序的行为提供权威资源，理想的规范即：
当前和未来的 Rust 版本定义了对给定 Rust 程序语义的规定边界
提供了与该规范实例耦合的 Rust 版本的语义的详细描述。
关于特定版本的详细信息可以直接在规范中提供，也可以通过委派给相关 Rust 团队拥有的其他文档间接提供。
发布节奏
Rust 发布将独立于规范审批流程进行，这是从设计方面考虑的。规范工作不得为项目增加需要克服的新障碍，以履行其现有义务，例如 6 周的发布周期。
团队愿景是最终能够达到自动交付更新规范的程度，并且能够按照项目的 6 周发布节奏完成。但是，从短期和中期来看，其希望能够自由地滞后于 6 周的发布节奏。当规范团队为以前未涉及的领域逐步添加新内容，或大幅缩小当前版本规范的规定范围时，滞后于 Rust 发布计划的能力可能会特别有用。
虽然规范开发过程不会阻止发布，但语言功能的更改应与规范的相关更新相结合。一旦开始发布与特定版本相关的规范，那么如果没有规范团队批准对当前草案规范的相应拉取请求，则对当前规范中记录的语言功能的更改就无法稳定。规范中未记录的语言功能的更改可以在不更新规范的情况下稳定下来，但需要规范团队成员确认相应的功能未记录。
通过强制执行新功能在稳定之前必须成为规范的一部分的规则，有望消除规范与 Rust 版本之间潜在滞后的主要根源。
（责编： admin）
免责声明：本文为转载，非本网原创内容，不代表本网观点。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
