团队和仓库标签

Swift Specs 仓库

此存档不再活跃。内容保留用于历史目的。

此仓库中的文档是想法的集合。它们不一定是功能的正式设计，也不是功能的文档，也不是未来功能的路线图。

这是一个用于对 OpenStack Swift 增强进行设计评审的 git 仓库。这提供了一种确保每个人在早期就对解决问题的方法达成共识的能力。

仓库结构

仓库的结构如下

specs/
    done/
    in_progress/

一旦相关的代码提交，已实现的规范将被移动到 已完成目录。

想法从你的头脑到实施的流程

首先，将规范提交到in_progress目录，以便进行评审。评审者在 gerrit 中添加积极的 +1/+2 评审，承诺在代码提交时进行评审。规范文档应尽快批准和合并，并且in_progress目录中的规范文档可以根据需要随时更新。不断迭代。

1. 有一个想法
2. 提交一个规范
3. 评审者评审规范。一旦 2 名核心评审者喜欢它，就合并它。根据需要随时迭代规范，并使其保持最新。
4. 一旦对规范达成一致，就编写代码。
5. 随着代码在评审期间的变化，根据需要随时更新规范。
6. 一旦代码提交（包含所有必要的测试和文档），规范可以移动到done目录。如果一个功能需要规范，它需要文档，并且文档必须在功能之前或与功能一起提交（而不是之后）。

规范生命周期规则

1. 快速落地：规范是一个活文档，存在于仓库中而不是 gerrit 中。潜在用户、运维人员和开发人员会查看 https://specs.openstack.org/openstack/swift-specs/ 以了解正在进行的工作，因此它们需要快速落地。
2. 初始版本是一个想法，而不是技术设计：这样就可以讨论和落地想法的优点，而不会陷入 gerrit 的僵局。
3. 第二个版本是技术设计的概述：这将有助于社区内的技术讨论。
4. 后续版本改进/增强技术设计：这些版本中的每一个都应该相对较小的规范补丁，以遵守规则 #1。并使规范与实施的进度保持同步。

如何提问并澄清规范

自然地，你希望澄清规范的编写方式。要提问，请通过正常的补丁提交工具向规范提交一个补丁，其中包含你的问题或你对令人困惑的部分的理解。这将会在补丁评审中提出问题，并允许每个人回答或评论。

在实践中学习

这是一种尝试新事物的方式，因此我们将从一开始就采用低流程，以确定我们下一步该怎么做。预计在一段时间内，这项工作会具有一定的灵活性。