<div dir="ltr">Was: <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-February/057578.html">http://lists.openstack.org/pipermail/openstack-dev/2015-February/057578.html</a><br><br>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.<br><br><br><div>Currently we follow a 6 month release cadence, with 3 intermediate milestones (6 weeks apart), as explained here: <a href="https://wiki.openstack.org/wiki/Kilo_Release_Schedule">https://wiki.openstack.org/wiki/Kilo_Release_Schedule</a><br><br><br>Current issues</div><div><ul><li>3 weeks of feature freeze for all projects at the end of each cycle (3 out of the 26 feature blocked)</li><li>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. </li><li>some projects have non priority feature freezes and at Milestone 2 (so 9 out of 26 weeks restricted in those projects)</li><li>vicious development circle</li><ul><li>vicious circle:</li><ul><li>big push right to land lots of features right before the release</li><li>a lot of effort is spent getting the release ready</li><li>after the release people are a little burnt out and take it easy until the next summit</li><li>Blueprints have to be re-discussed and re-approved for the next cycle</li><li>makes it hard to land blueprints early in the cycle casing the bug rush at the end of the cycle, see step 1</li></ul><li>Makes it hard to plan things across a release</li><li>This actually destabilizes things right as we go into the stabilization period (We actually have great data on this too)</li><li>Means postponing blueprints that miss a deadline several months</li></ul></ul><div><br></div><div>Requirements for a new model</div><div><ul><li>Keep 6 month release cadence. Not everyone is willing to deploy from trunk</li><li>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</li><li>Keep supporting continuous deployment. Some people really want to deploy from trunk</li></ul><div><br></div></div><div>What We can drop</div><div><ul><li>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</li></ul></div><div><br></div><div>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.</div><div><br></div><div>What this actually means:</div><div><ul><li>Stop approving blueprints for specific stable releases, instead just approve them and target them to milestones.</li><ul><li>Milestones stop becoming Kilo-1, Kilo-2, Kilo-3 etc. and just become 1,2,3,4,5,6,7,8,9 etc.</li><li>If something misses what was previously known as Kilo-3 it has to wait a week for what for milestone 4.</li></ul><li>Development focuses on milestones only. So 6 week cycle with say 1 week of stabilization, finish things up before each milestone</li><li>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</li><li>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</li></ul></div><div><br></div><div>Gotchas, questions etc:</div><div><ul><li>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</li><li>Requires significantly more work from the stable maintenance team</li><li>Naming the stable branches becomes less fun, as we refer to the stable branches less</li><li>Since planning is continuous 6 month cycle for summits becomes a little strange. This is still an open ended question to me.</li></ul><div><br></div></div></div><div><br></div><div>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.</div></div>