关于新库的提案¶
Oslo（作为一个组织和项目）经常被要求创建（或采用）新的库，用于各种目的（有些相关，有些不相关），因此，作为一个组织，就新库和它们需要经历的过程达成共识是好的，以便它们要么成为 Oslo 中的一个新库（Oslo 组织将拥有并继续维护），要么成为在 pypi（或其他两种方法的混合）上独立维护的新库。
问题描述¶
假设开发者Bob希望为 OpenStack 项目创建新的库。
此时，Bob 在构建这个库时有几个选择
将库与 Oslo 项目保持独立。在某个代码仓库站点创建库，并从该库中生成一个功能完善且有用的制品（通常是 pypi 发布），并在创建该制品后将其集成到各种 OpenStack 项目中。
这其中的一些优点是
Bob 可以按照自己的节奏工作、发布、迭代。
更广泛的 Python 社区可以立即开始采用。
这其中的一些缺点是
在库最初未集成到任何项目中时，很难定义/找到库的目的（通常，创建一个好的库有助于拥有一个积极使用该库的用户来提供反馈）。
存在采用（在更大的 Python 社区或总体上）可能不会发生的风险。
无法直接利用 Oslo 社区中积累的专业知识（评审、经验……）（即，创建者需要独自承担）。
在某个代码仓库站点创建库，并从该库中生成一个功能完善且有用的制品（通常是 pypi 发布），并将其集成到各种 OpenStack 项目中（可以由自己完成，也可以与他人合作），然后提出将该库转移到 Oslo 组织所有权，原因可能是所有者不再维护，但它被 OpenStack 项目广泛使用。
这其中的一些优点是（包括之前的选项的优点）
创建的库的持续维护（和评审）现在由 Oslo 评审人员（和组织）共同承担。
这其中的一些缺点是（包括之前的选项的缺点）
创建的库的持续维护（和评审）现在由 Oslo 评审人员（和组织）共同承担。创建者可能会失去控制权，必须遵守 Oslo 的政策。
关于这种方法，还有一些误解需要澄清（这些观念可能以前是合理的，但由于社区的变化，现在不应再被认为是正确的）。
在 Oslo 中采用并不能保证库的成功（仍然需要大量的说服和艰苦的工作才能取得成功）。
开放的环境使得库更容易集成到 OpenStack 生态系统的流程中，而无需加入 Oslo 也能从相同的生态系统流程中受益。
遵循此流程的示例 oslo 库
automaton
futurist
立即创建库，让 Oslo 组织或子组织（并默认使用 OpenStack 生态系统）帮助创建，并从该库中生成一个功能完善且有用的制品（通常是 pypi 发布），并将其集成到各种 openstack 项目中。
这其中的一些优点是（包括之前的选项的优点）
Oslo 组织拥有的专业知识（多年的经验、聪明的人）可以帮助指导库的成功。
创建的库的持续维护（和评审）现在由 Oslo 评审人员（和组织）共同承担。创建者可能会失去控制权，因为该项目现在受 Oslo 管辖，他们可以批准创建者可能不同意的规范和更改。
这其中的一些缺点是（包括之前的选项的缺点）
创建的库的持续维护（和评审）现在由 Oslo 评审人员（和组织）共同承担。
与上一项所述相同的误解。
遵循此流程的示例 oslo 库
tooz
debtcollector
oslo.privsep
在某个项目中创建库，证明它对其宿主项目有用（但不要过于特定于该宿主项目，以至于对其他人没有用处），然后将该库提取到某个代码仓库站点，并生成一个有用的制品。之后，该库的进一步维护将通过该代码仓库站点进行。
这其中的一些优点是
由于与宿主项目的集成，库的用途/目的将更加明确。
这其中的一些缺点是
用途/目的可能过于特定于宿主项目（并且需要进一步的提取/重构工作才能进行泛化）。
遵循此流程的示例 oslo 库
taskflow
oslo.versionedobjects
在宿主项目中创建源代码，当另一个宿主项目可以从相同的代码中受益时，将源代码提取到通用的孵化器中。然后，迭代孵化器中的版本，并定期将孵化器版本同步到宿主消耗项目中。在某个时候，当被认为稳定时，将孵化器的版本提取到库中，然后从该库中生成一个功能完善且有用的制品（通常是 pypi 发布）。之后，该库的进一步维护将通过新的库代码仓库站点进行（并且通常会遵循版本控制）。
这其中的一些优点是
由于与一组宿主项目的集成，库的用途/目的将更加明确。
这其中的一些缺点是
通常需要更多的迭代才能提取一个隔离的制品。
多轮非版本化的同步以及潜在的 API 冲突/冲突（由于孵化器的复制/粘贴例程）和更改迭代。
无法从一开始就获得更广泛的 Python 社区采用。
更难清理和跟踪。
实现可能会发生偏差，并且保持同步所需的工时量很大。
遵循此流程的示例 oslo 库
oslo.config
oslo.cache
oslo.concurrency
oslo.db
oslo.log
oslo.messaging
oslo.policy
oslo.serialization
…
Bob 还必须选择他将使用的代码仓库站点。为了本文档的目的，我们假设大多数人会选择使用 OpenStack 生态系统的 gerrit 评审系统和基于 git 的托管系统（但如果 Bob 愿意，他可以使用像 github 和 pull requests 这样的东西，只要 Bob 考虑到这样做会使来自 OpenStack 社区的贡献变得更加困难）。
拟议政策¶
为了帮助 Bob（或其他作者）从问题陈述中列出的选项中做出明智的选择，我们作为一个组织（已经多次做出这些决定）希望通过让新的库（及其作者）经历一种我们认为可以帮助库创建者确定上述哪些选项更适合他们（并且更适合他们自己库的未来成功）的 litmus test 来帮助新的库（及其作者）取得成功。
为了帮助这个过程，我们作为一个组织认为，当 Bob（或其他作者）开始确定他（或她）将采取哪个选项时，最好让该开发者填写 new-library-template.rst 模板，并将其发布到 openstack-discuss 邮件列表中，主题中带有 [oslo] 标签。然后让邮件列表确定上述哪个选项最适合作者和整个社区）。如果邮件列表同意它应该成为一个新的 oslo 库，则应将相同的信息也提交到 oslo-specs 仓库。
为了使新的 oslo 库保持健康和持续开发，需要新的核心贡献者来维护该库，至少需要两个社区成员承诺及时处理错误分类和修复，以及响应测试失败。
替代方案与历史¶
其他选项更像是 Oslo 组织已经做的事情，即围绕新库和开发者想要（或愿意）创建新库的可用选项，存在一种即兴的和部落知识。这项政策旨在将这些知识巩固成一份易于参考和达成一致的文件。
实现¶
里程碑¶
Pike
工作项¶
草案政策
获取政策反馈
重复
批准政策
参考资料¶
修订历史¶
发布名称 |
描述 |
|---|---|
Pike |
引入 |
注意
本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode
