最新变化：OpenStack发布周期或将延长至1年

Posted 2021-04-24 牛皮糖的碎碎念

今天，openstack-dev邮件列表里最热的topic是由TC老大Thierry Carrez发起的一则讨论：”Switching to longer development cycles“。

ttx期望将当前的Release周期从半年更改为一年，是基于以下现状：

• 自我驱动的社区开发速度已经跟不上频繁的选举和特性冻结速度了（PTL选举和Release均半年一次），Release中的Milestone已经失去了意义（约1.5个月发布一个Milestone）

• 随着各组件的逐渐成熟，越来越少的功能需要快速开发和发布了

• 随着越来越多的人使用OpenStack，需要投入更多的时间来保证兼容性和稳定性

• OpenStack越来越复杂，需要投入比以前更多的时间进行测试

• 当前Release模型的迭代速度是针对代码贡献者是作为全职开发而设计的。但随着当前OpenStack组件的发展，越来越少的人能够100%精力地投入到某一个项目中，更多的是分散到多个项目或者是其他开源项目
  

Release周期变为一年，这意味着：

• 每年只发布一个OpenStack版本并且只维护一个稳定分支

• PTL选举变为每年一次

• 每年只设定一个社区目标

• 每年只有一次PTG
  

这并不意味着：

• 所有组件只有更少的发布频次或者更晚的发布时间。如果必要，各个项目仍然可以使用cycle-with-intermediary发布模型进行发布，一年一次只是发布周期的下限。

• 鼓励开发速度放缓变慢。各个项目可以自行调整开发速度，继续使用sprint，milestone来管理开发计划，一年一次的发布周期是希望有更高的发布质量

• team成员的面对面交流只有一次。期望通过team组织的中期讨论会来替代原先的第二次PTG。

• 简化升级。影响升级速度并不取决于开发周期的变化，而是每次升级的耗时，当然一年一次的升级会比一年两次的升级稍微好一些。

• 发布LTS。发布周期变长，因此同一时间需要维护的分支变少了，但并不表示会发布长期支持的版本。

何时？

明年2/3月或者8/9月作为新版本发布的起始时间点。

谁来决策？

目前已在release team进行了讨论，将在openstack社区收集意见，最终由TC（技术委员会）投票决定。

---

社区的反应

炸开了锅。

今早5点（NZT时区）ttx发出的邮件，截止到现在12点已经40封邮件了，赞同点赞的，持怀疑态度的，反对的，各种声音都有，看来democracy真是麻烦，还是应该向素来全票通过的某组织学习。

目前可以看得出支持发布周期改为一年的更多，而且邮件里几位TC成员在探讨周期调整的细节和策略了，因此在这一变化在TC决策上得以通过是大概率事件。

---

我个人认为这是一件好事，作为一名OpenStack社区的参与者和用户，最近几年社区存在以下两点较为明显的问题：

贡献者的持续减少

这里说的贡献者是指全职的开源社区工程师，不是指那些靠修改个标点符号或者语法的开源刷子。以最新的Pike版本为例，Nova可以算是Openstack中最热门，关注度最高的核心项目，releaste note的feature list满满一堆，能算得上亮点的可能只有一条：Cells v2 multi-cell deployment。

更别说其他非核心项目和非热门项目了，前段时间Openstack-Chef的PTL在ML更是发出了类似Donald Trump竞选宣言的邮件：Making the Kitchen Great Again，引得众多项目的PTL纷纷效仿。

OpenStack的活跃度不如以前是件正常的事情，当年Cloud是热点，并且OS一枝独秀，现在则是百花齐放。从12年到现在，当年认识的OpenStack工程师虽多数还和Cloud相关，有不少已经离开了OpenStack领域：一部分从虚机转做Docker和K8S，一部分去做当前热门的机器学习和Tensorflow，一部分从Neutron转攻底层SDN，一部分从Cinder，Glance专攻存储Ceph，等等。这并不意味着OS社区的凋零，而是逐渐发展成熟之后，作为一项常见的IT技术不会再被广泛关注，如同Linux一样。

发布周期过于频繁

OpenStack当前的发布周期是6个月，每个周期包括一次Desgin summit（在大家熟知的OpenStack Summit中进行），三次Milestone，FF阶段以及RC发布阶段：

这不仅对于社区开发来说速度早已脱节，对于其他工程师（ops, test)更是一场梦魇。

我曾详细推算过上线OpenStack最新版本的时间点：

• 从社区发布正式版本到RDO/Ubuntu Cloud Archive发布Stable的软件包约需1个月

• 从开发部门进行功能调研和代码合并需1个月（由于私有化patch数量的增长，合并会越来越难）

• 从测试部门完成性能，高可用，场景测试方案到实现需要半个月（随着支持服务数量的增长，时间会延长）

• 从测试环境部署到预发布环境观察运行情况，1个月

• 从预发布部署到线上环境，可能由于各种原因，推迟半个月甚至一个月都是正常的（随着集群数量的增加，时间会延长）

也就是等我们上线新版本X的时候，下个版本Y已经发布最后一个Milstone了，或者赶上了下一版本的Feature Freeze...

若是市场部的稿子慢一点，可能都不好意思标榜是最新版本了。一个月后，客户问你这是社区最新的Y版本吗？售前一副生无可恋的样子。

而将开发周期从半年调整到一年，可以在当前大环境下开发者减少的情况下，继续保证代码的质量和功能，让开发/测试/运维人员有更充足的时间进行准备，这比掐着6个月发布一堆冰冷的版本号更有价值。