Open Stack

Was:
http://lists.openstack.org/pipermail/openstack-dev/2015-February/057578.html

There has been frustration with our current 6 month development cadence.
This is an attempt to explain those frustrations and propose a very rough
outline of a possible alternative.


Currently we follow a 6 month release cadence, with 3 intermediate
milestones (6 weeks apart), as explained here:
https://wiki.openstack.org/wiki/Kilo_Release_Schedule


Current issues

   - 3 weeks of feature freeze for all projects at the end of each cycle (3
   out of the 26 feature blocked)
   - 3 weeks of release candidates. Once a candidate is cut development is
   open for next release. While this is good in theory, not much work actually
   starts on next release.
   - some projects have non priority feature freezes and at Milestone 2 (so
   9 out of 26 weeks restricted in those projects)
   - vicious development circle
      - vicious circle:
         - big push right to land lots of features right before the release
         - a lot of effort is spent getting the release ready
         - after the release people are a little burnt out and take it easy
         until the next summit
         - Blueprints have to be re-discussed and re-approved for the next
         cycle
         - makes it hard to land blueprints early in the cycle casing the
         bug rush at the end of the cycle, see step 1
      - Makes it hard to plan things across a release
      - This actually destabilizes things right as we go into the
      stabilization period (We actually have great data on this too)
      - Means postponing blueprints that miss a deadline several months


Requirements for a new model

   - Keep 6 month release cadence. Not everyone is willing to deploy from
   trunk
   - Keep stable branches for at least 6 months. In order to test upgrades
   from the last stable branch, we need a stable branch to test against
   - Keep supporting continuous deployment. Some people really want to
   deploy from trunk


What We can drop

   - While we need to keep releasing a stable branch every 6 months, we
   don't have to do all of our development planning around it. We can treat it
   as just another milestone


I think a lot of the frustration with our current cadence comes out of the
big stop everything (development, planning etc.), and stabilize the release
process. Which in turn isn't really making things more stable. So I propose
we keep the 6 month release cycle, but change the development cycle from a
6 month one with 3 intermediate milestones to a 6 week one with a milestone
at the end of it.

What this actually means:

   - Stop approving blueprints for specific stable releases, instead just
   approve them and target them to milestones.
      - Milestones stop becoming Kilo-1, Kilo-2, Kilo-3 etc. and just
      become 1,2,3,4,5,6,7,8,9 etc.
      - If something misses what was previously known as Kilo-3 it has to
      wait a week for what for milestone 4.
   - Development focuses on milestones only. So 6 week cycle with say 1
   week of stabilization, finish things up before each milestone
   - Process of cutting a stable branch (planning, making the branch, doing
   release candidates, testing etc.) is done by a dedicated stable branch
   team. And it should be done based on a specific milestone
   - Goal: Change the default development planning mode to ignore stable
   branches, and allow for us to think of things in terms of the number of
   milestones needed, not will it make the stable branch or not


Gotchas, questions etc:

   - Some developers will still care about getting a feature into a
   specific stable release, so we may still get a small rush for the milestone
   before each stable branch
   - Requires significantly more work from the stable maintenance team
   - Naming the stable branches becomes less fun, as we refer to the stable
   branches less
   - Since planning is continuous 6 month cycle for summits becomes a
   little strange. This is still an open ended question to me.



Anyway, that has been rattling around my head since Paris and I needed to
write it down somewhere. Thanks for reading. Thoughts, comments, concerns
welcome.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150223/bed378ee/attachment.html>