Russell Bryant 两周前 发起 了关于技术委员会 (“TC”) 正在做什么的一系列博客文章。 我们将定期发布 TC 会议结果，并轮换作者，以便所有 TC 成员都有机会参与并用自己的话描述发生的事情。 本文将重点介绍最近两次会议上发生的事情。

TC 有几个使命，我们 TC 会议中讨论的主题通常属于其中一个使命。

使命 #1：集成发布内容

TC 的一项使命是确定 OpenStack “集成发布” 的内容，我们每 6 个月共同制作一次。 我们管理 “孵化” 过程，通过该过程，选定的项目可以成为集成发布的一部分。 我们还会关注已经集成的项目，以防其范围发生变化。

目前 Glance 就是这种情况，其使命正在从编目和提供 Nova 磁盘镜像发展到编目和提供其他由其他 OpenStack 服务消耗的工件，例如 Heat 模板。 这种范围的演变在最近两次会议上一直在讨论中。 扩大 Glance 范围的原则在这一点上基本被接受，但描述新范围的精确措辞仍在讨论中。

为了为孵化/集成过程中的项目设定明确的基本期望，上一个周期 TC 发布了一个 参考文档，其中列出了 TC 成员一致认可的孵化、集成和首次集成周期的所有要求。 该文档会不断修订，因为我们继续提高集成项目之间的质量和收敛标准。

最近两次会议上，我们一直在讨论为希望从孵化阶段毕业的项目添加 翻译支持要求。 目前的主要反对意见是缺乏对翻译字符串的自动化测试（这导致过去出现未检测到的 I18N 问题）。 看起来当这个问题得到解决时，这个要求可能会被添加到参考文档中。

提高对新参与者的要求是一回事，但有时现有的集成项目不符合这些新要求。 这就产生了一个我们需要解决的差距。 在这个周期中，我们审查了大多数现有集成项目（Heat 和 Swift 仍在待定）。 当出现差距时，PTL 会提出一个 “差距覆盖计划” 来解决它。

最后一个经过此过程的项目是 Glance，其中提出了一个关于测试覆盖率的差距。 Mark Washenberger（Glance PTL）创建了一个 差距覆盖计划 来解决它，并且该计划在上次会议上得到了 TC 的批准。

制定计划是一回事，但我们还需要检查项目是否能满足他们在此类计划中设定的截止日期。 上周，在 juno-1 开发里程碑之后，我们审查了差距覆盖计划的进展情况。 Ceilometer 计划 进展顺利，仍计划在 juno-2 里程碑上完全覆盖差距。 Horizon 计划 大部分进展顺利。 Neutron 有一个雄心勃勃的 差距覆盖计划，并且已经开始解决所有差距；差距 4 有点晚（计划在 juno-1 完成），但也被确定为只是一个 API 调用。 Trove 计划 进展顺利，并且已经开始处理所有项目。

最后，对集成发布负责意味着确保我们在集成项目中使用术语的一致性。 有人提出了关于在某些项目中使用 “认证” 术语来限定 CI 测试的问题。 在 -dev 邮件列表和 TC 会议上进行公开 讨论 之后，大家一致认为 “认证” 术语过于复杂，应逐步淘汰，而采用围绕 “测试” 的一些变体。

使命 #2：代表技术贡献者

TC 是一个直接选举产生的机构，代表 OpenStack 的所有技术贡献者。 它是 OpenStack 整体技术事务的最终决策实体。 无法在较低级别解决的一些问题有时会被升级到 TC 以供最终解决，TC 也是 OpenStack 其他治理机构寻求一般技术意见的便捷渠道。

最近有两个问题被提交给 TC。 第一个是关于我们的技术选举（PTL 和 TC 成员）的预期选举行为。 我们当前的选举程序没有明确描述预期的行为，并且有人提出要解决这个问题。 虽然每个人都同意什么是可接受的行为，什么是不可以接受的行为，但如果出现问题，有两种处理方法。 一种 是 piggy-back 到社区行为准则，该准则明确指出您应该尊重选举过程。 另一种 是指出不合规的行为，并相信选民自己判断。 两种选择都将保持可用，但我们仍在讨论是否应该通过将其纳入 TC 决议来鼓励其中一种选择。 此讨论正在进行中，并将继续在未来的会议上进行。

另一个提交给 TC 的问题是来自基金会董事会 “Defcore” 小组委员会的技术意见请求，用于作为其商标规则工作的一部分。 有两种类型的请求输入。 一种 是为每个项目提供 “指定部分” 的代码，您需要运行这些代码才能使用 “OpenStack” 商标。 另一种是提供关于 “核心能力” 的精确 评分：对于每个能力，指出它是否是 TC 未来的方向的一部分，或者它是否正在被弃用。

虽然这些输入是技术性的（我们甚至对 指南 进行了投票，以帮助提出答案），但一些 TC 成员明确表示他们感到不舒服。 要求代表 OpenStack 贡献者指定 OpenStack 的部分，这些部分可能只是被专有替代品取代（但仍然被称为 “OpenStack”），这超出了他们认为可以接受的范围。 我们的 “技术” 答案可能会被解读为认可，或者与我们不想鼓励的行为合作。

这种紧张关系每次在 TC 会议上讨论 Defcore 时都会浮出水面，很难在一个小时的在线会议中解决这两个主题。 因此，我们已安排在 7 月 1 日（协调世界时 20:00 在 Freenode IRC 上的 #openstack-meeting）举行一次 Defcore 专属的 TC 会议，并尝试提前明确列出疑虑，以确保会议清晰。