Ballistic Release Cycles: Tracking the Trajectory of OpenStack Milestones

I’ve been watching a pattern emerge on the semiannual OpenStack release cycles for a while now. There is a hidden but crucial development phase that accelerates projects faster than many observers realize. In fact, I believe that substantial work is happening outside of the “normal” design cycle during what I call “free fall” development.

Understanding when the cool, innovative stuff happens is essential to getting (and giving) the most from OpenStack.

The published release cycle looms like a 6 stage ballistic trajectory. Launching at the design summit, the release features change and progress the most in the first 3 milestones. At the apogee of the release, maximum velocity is reached just as we start having to decide which features are complete enough to include in the release. Since many are not ready, we have to jettison (really, defer) partial work to ensure that we can land the release on schedule.

I think of the period where we lose potential features as free fall because thing can go in any direction. The release literally reverses course: instead of expanding, it is contracting. This process is very healthy for OpenStack. It favors code stability and “long” hardening times. For operators, this means that the code stops changing early enough that we have more time to test and operationalize the release.

But what happens to the jettisoned work? In free fall, objects in motion stay in motion. The code does not just disappear! It continues on its original upward trajectory.

The developers who invested time in the code do not simply take a 3 month sabbatical, nor do they stop their work and start testing the code that was kept. No, after the short in/out sorting pause, the free fall work continues onward with rockets blasting. The challenge is that it is now getting outside of the orbit of the release plan and beyond the radar of many people who are tracking the release.

The consequence of this ongoing development is that developers (and the features they are working on) show up at the summit with 3 extra months of work completed. It also means that OpenStack starts each release cycle with a bucket of operationally ready code. Wow, that’s a huge advantage for the project in terms of delivered work, feature velocity and innovation. Even better, it means that the design summit can focus on practical discussions of real prototypes and functional features.

Unfortunately, this free fall work has hidden costs:

  • It is relatively hidden because it is outside of the normal release cycle.
  • It makes true design discussions less productive because the implemented code is more likely to make the next release cycle
  • Integration for the work is postponed because it continues before branching
  • Teams that are busy hardening a core feature can be left out of work on the next iteration of the same feature
  • Forking can make it hard to capture bugs caught during hardening

I think OpenStack greatly benefits from free fall development; consequently, I think we need to acknowledge and embrace it to reduce its costs. A more explicit mid-release design synchronization when or before we fork may help make this hidden work more transparent.

9 thoughts on “Ballistic Release Cycles: Tracking the Trajectory of OpenStack Milestones

  1. Note that there are only 4 weeks between feature freeze and opening of the next release branch, only 6 weeks between feature freeze and release, and only 8 weeks between feature freeze and the next Design Summit.

    So it’s not 3 months, but I see your point in needing to recognize the work that is done in free fall while still focusing on release delivery.


    • Thierry – thanks for the corrections. You’re right and I’m updating so they do not distract from my point; however, I’m see that technical feature freeze is in the middle of the free fall zone. I seems to me that developers are jumping to focusing on the next release as soon as they realize that their work won’t make the freeze.


    • I can see a source of confusion looking at the official release dates Thierry lists and the events that I’m highlighting. I’m not sure how to correct in the post. Yes, the actual OpenStack release plan events happen later than I am implying. In my experience with numerous releases, features that will not be ready are pulled early and voluntarily if they cannot make the official dates in advance of feature freeze.

      In OpenStack, there is a tremendous advantage to showing up at the summit with working code and this drives the effect that I am trying to highlight.


  2. Pingback: Continuous Release combats disruptions of “Free Fall” development « Rob Hirschfeld's Blog

  3. Pingback: My Dilemma with Folsom – why I want to jump to G « Rob Hirschfeld's Blog

  4. Pingback: OpenStack Board Voting Starts! Three thoughts about the board and election « Rob Hirschfeld's Blog

  5. Pingback: How to work with blueprints without losing your mind | Victoria Martínez de la Cruz

  6. Pingback: Cómo trabajar con blueprints sin perder la cabeza | Victoria Martínez de la Cruz

  7. Pingback: openstack,如何用自己的想法和blueprint协同工作 | CloudOps

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s