Success Bot Says
- mordred 在 #openstack-sdks 上说：“完成了 shade 向纯 REST 的过渡，不再使用客户端库” [0]
- 使用命令“#success <评论>”在 OpenStack IRC 频道中分享您的成功。
[0] – http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2017-12-04.log.html
社区总结
- TC 报告 50 [0]
- POST /api-sig/news [1]
- 发布倒计时 [2]
- 技术委员会状态更新 [3]
- 资源提供者更新 45 [4]
切换到更长的开发周期
我们自行设定的节奏不再符合我们的自然步调。我们的选举、功能冻结感觉就在眼前，并且由于这个原因，我们正在失去时间，正如许多人所说。这个节奏是围绕着更多的人全职贡献 OpenStack 设计的，但最近，我们有复合工作，或者参与多个社区（这很好！）。
这意味着
- 每年一次 OpenStack 协调发布。
- 维护每年一个稳定的分支。
- 每年选举一次 PTL。
- 每年制定一套社区目标。
- 每年一次 PTG。
任何仍然希望频繁发布的项目都可以使用带有中间发布的周期模型 [0]。至少，我们将每年发布一次。团队可以选择在需要时恢复中期发布以满足每年一次 PTG 的需求。我们将有更多的时间来实现社区范围内的目标，因此我们将有更多的时间来完成甚至设定更雄心勃勃的目标。
这并不能简化升级。虽然每年升级比被迫每 6 个月升级要好一点。真正的解决方案是更好地支持跳过发布。
它也不会给我们提供 LTS。维护分支的成本并不真正取决于并行分支的数量，而是取决于最旧分支的年龄。真正的解决方案正在由（仍在组建中的）LTS SIG 讨论中。扩展稳定性周期目前是每个项目的决定，并且该提案尚未解决协调的稳定性周期。
我们计划以事件的组织方式来确定一年。建议从 Rocky 发布开始，并在 2018 年在都柏林举行一次 PTG。发布团队正在向社区开放讨论，TC 将做出最终决定。
表达了各种反对意见，例如这会导致在发布结束时争相提交代码，以避免等待整整一年。项目也被迫对版本化的 API、配置文件等进行兼容性支持，因为项目将无法在中间发布中放弃兼容性。像 Grenade 这样的项目将不得不支持一些项目进行中间发布，而另一些项目进行年度发布的情况。
对于那些花费 20% 的时间为 OpenStack 做出贡献的人来说，有人表示，让一个功能合并需要时间，而当前的周期使其不可能。更长的开发周期可以帮助那些人有更多的时间。许多人表示，我们应该着眼于帮助我们的兼职贡献者的根本原因，因为周期的长度不太可能是原因。只有 20% 时间可以贡献的人也很可能需要处理重新合并冲突，而不是专注于他们的代码。
一年也可能意味着需要中间发布，以便规范可以每年多次获得批准。但是，如果这样，这将给核心团队带来压力，需要与这些精确的计划相匹配，而该提案旨在缓解这种情况。人们担心这更多的是解决了让更多人有机会考虑他们的规范/新功能的问题。
这个话题过去也多次被提出。有人提到 Daniel Berrange 的帖子 [1]
Zuul Dashboard 可用
除了显示“状态”的 Zuul dashboard [0] 之外，还添加了其他选项卡。“Jobs”页面显示系统中所有作业及其描述。“Builds”页面列出了最近的运行。您可以查询管道、作业和项目。
安全 SIG
在之前的邮件列表讨论之后 [0]，安全项目将转变为一个特殊兴趣组 (SIG)。事实证明，SIG 非常适合围绕社区的开发人员、操作员和用户的主题或实践所做的工作。该小组将继续管理和维护安全指南、OSSNs、Bandit、Thread Reviews、Syntribos，以及鼓励和孵化新的安全项目。该小组将继续与 VMT 合作，并为启动板保留一个 Sec-core 组，该组可以处理禁运问题。
周期亮点提醒
随着我们越来越接近 Queens-3 和我们的最终 RC，提醒大家关于添加到交付信息中的新“cycle-highlights”。添加此功能的原因是，一些 PTL 在每个发布周期中都会被各种人（如记者、产品经理等）多次 ping，以编译相同的信息。为了缓解这种情况，我们有一种方法可以在发布中捕获亮点。这将提供基本信息，但不是完整的营销信息。
这在 openstack/releases 仓库的 deliverables/queens/$PROJECT.yaml 文件中以如下格式完成
cycle-highlights
– 引入新的服务来使用未使用的主机来挖比特币。
我们有三个不同的地方记录了针对三个不同受众的活动
提交消息：开发者文档
发布说明：最终用户和部署者文档
周期亮点：记者、产品经理等。
Rocky 的社区目标
一些需要问自己的问题：我们有哪些共同的挑战，以及谁愿意推动这个社区范围内的目标（即倡导者）。
倡导者是推动目标的人，但不一定承诺编写代码。倡导者将与项目 PTL 沟通目标，并在需要时进行联络。
社区范围内的目标想法列表收集在此 etherpad [0] 上。现在提出一些想法！
发表评论