<div><span style="font-size: 14px;">IMHO, killing releases, or shortening the cycles, would add up a lot more</span>
</div><div><span style="font-size: 14px;">of work to stable maintainers and harder to track cross project dependencies.</span></div><div><span style="font-size: 14px;"><br></span></div><div><span style="font-size: 14px;">Specially for dependencies and cross version dependencies.</span></div><div><span style="font-size: 14px;"><br></span></div><div><div><span style="font-size: 14px;">Also deployment changes will make everybody’s life harder.</span></div></div><div><span style="font-size: 14px;"><br></span></div><div><span style="font-size: 14px;">IMO it’s a matter of better coordination, and shortening the spec submission</span></div><div><span style="font-size: 14px;">timeframe, even moving it back to the end of the previous cycle, so it’s clear</span></div><div><span style="font-size: 14px;">what should be the community focus for a certain cycle.</span></div><div><br></div><div><span style="font-size: 14px;">The neutron driver team & PTL have done a good work in this regard.</span></div>
<div><div><br></div><div><span style="font-size: 10pt;">Miguel Ángel Ajo</span></div><div><br></div></div>
<p style="color: #A0A0A8;">On Tuesday, 24 de February de 2015 at 11:59, Daniel P. Berrange wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>On Mon, Feb 23, 2015 at 04:14:36PM -0800, Joe Gordon wrote:</div><blockquote type="cite"><div><div>Was:</div><div><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></div><div><br></div><div>There has been frustration with our current 6 month development cadence.</div><div>This is an attempt to explain those frustrations and propose a very rough</div><div>outline of a possible alternative.</div><div><br></div><div><br></div><div>Currently we follow a 6 month release cadence, with 3 intermediate</div><div>milestones (6 weeks apart), as explained here:</div><div><a href="https://wiki.openstack.org/wiki/Kilo_Release_Schedule">https://wiki.openstack.org/wiki/Kilo_Release_Schedule</a></div><div><br></div><div><br></div><div>Current issues</div><div><br></div><div> - 3 weeks of feature freeze for all projects at the end of each cycle (3</div><div> out of the 26 feature blocked)</div><div> - 3 weeks of release candidates. Once a candidate is cut development is</div><div> open for next release. While this is good in theory, not much work actually</div><div> starts on next release.</div><div> - some projects have non priority feature freezes and at Milestone 2 (so</div><div> 9 out of 26 weeks restricted in those projects)</div><div> - vicious development circle</div><div> - vicious circle:</div><div> - big push right to land lots of features right before the release</div><div> - a lot of effort is spent getting the release ready</div><div> - after the release people are a little burnt out and take it easy</div><div> until the next summit</div><div> - Blueprints have to be re-discussed and re-approved for the next</div><div> cycle</div><div> - makes it hard to land blueprints early in the cycle casing the</div><div> bug rush at the end of the cycle, see step 1</div><div> - Makes it hard to plan things across a release</div><div> - This actually destabilizes things right as we go into the</div><div> stabilization period (We actually have great data on this too)</div><div> - Means postponing blueprints that miss a deadline several months</div><div><br></div><div><br></div><div>Requirements for a new model</div><div><br></div><div> - Keep 6 month release cadence. Not everyone is willing to deploy from</div><div> trunk</div><div> - Keep stable branches for at least 6 months. In order to test upgrades</div><div> from the last stable branch, we need a stable branch to test against</div><div> - Keep supporting continuous deployment. Some people really want to</div><div> deploy from trunk</div><div><br></div><div><br></div><div>What We can drop</div><div><br></div><div> - While we need to keep releasing a stable branch every 6 months, we</div><div> don't have to do all of our development planning around it. We can treat it</div><div> as just another milestone</div><div><br></div><div><br></div><div>I think a lot of the frustration with our current cadence comes out of the</div><div>big stop everything (development, planning etc.), and stabilize the release</div><div>process. Which in turn isn't really making things more stable. So I propose</div><div>we keep the 6 month release cycle, but change the development cycle from a</div><div>6 month one with 3 intermediate milestones to a 6 week one with a milestone</div><div>at the end of it.</div></div></blockquote><div><br></div><div>You're solving some issues around developer experiance by letting developers</div><div>iterate on a faster cycle which is something I agree with, but by keeping</div><div>the 6 month release cycle I think you're missing the bigger opportunity here.</div><div>Namely, the chance to get the features to the users faster, which is ultimtely</div><div>the reason why contributors currently push us so hard towards the end of the</div><div>release. I think we have to be more ambitious here and actually make the release</div><div>cycle itself faster, putting it on a 2 month cycle. More detail about why I think</div><div>this is needed is here:</div><div><br></div><div> <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-February/057614.html">http://lists.openstack.org/pipermail/openstack-dev/2015-February/057614.html</a></div><div><br></div><blockquote type="cite"><div><div>What this actually means:</div><div><br></div><div> - Stop approving blueprints for specific stable releases, instead just</div><div> approve them and target them to milestones.</div><div> - Milestones stop becoming Kilo-1, Kilo-2, Kilo-3 etc. and just</div><div> become 1,2,3,4,5,6,7,8,9 etc.</div><div> - If something misses what was previously known as Kilo-3 it has to</div><div> wait a week for what for milestone 4.</div><div> - Development focuses on milestones only. So 6 week cycle with say 1</div><div> week of stabilization, finish things up before each milestone</div><div> - Process of cutting a stable branch (planning, making the branch, doing</div><div> release candidates, testing etc.) is done by a dedicated stable branch</div><div> team. And it should be done based on a specific milestone</div><div> - Goal: Change the default development planning mode to ignore stable</div><div> branches, and allow for us to think of things in terms of the number of</div><div> milestones needed, not will it make the stable branch or not</div><div><br></div><div><br></div><div>Gotchas, questions etc:</div><div><br></div><div> - Some developers will still care about getting a feature into a</div><div> specific stable release, so we may still get a small rush for the milestone</div><div> before each stable branch</div><div> - Requires significantly more work from the stable maintenance team</div></div></blockquote><div><br></div><div>I think we can increase the release cycle to 2 months without impacting the</div><div>stable team to any great extent. We simply don't have to provide stabel branches</div><div>for every single release - compare with Linux, only a subset of major releases</div><div>get stable branches & that generally works pretty well.</div><div><br></div><blockquote type="cite"><div><div> - Naming the stable branches becomes less fun, as we refer to the stable</div><div> branches less</div><div> - Since planning is continuous 6 month cycle for summits becomes a</div><div> little strange. This is still an open ended question to me.</div></div></blockquote><div><br></div><div>Simply stop calling them (release) design summits and call them conferences.</div><div>ie just have them be a forum for general developer & project collaboration &</div><div>communication. I'm not saying turn them into a series of presentation slots,</div><div>just don't portray them as the place where the next release is "designed",</div><div>let them be a more flexible general purpose forum.</div><div><br></div><div>Regards,</div><div>Daniel</div><div>-- </div><div>|: <a href="http://berrange.com">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/">http://www.flickr.com/photos/dberrange/</a> :|</div><div>|: <a href="http://libvirt.org">http://libvirt.org</a> -o- <a href="http://virt-manager.org">http://virt-manager.org</a> :|</div><div>|: <a href="http://autobuild.org">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/">http://search.cpan.org/~danberr/</a> :|</div><div>|: <a href="http://entangle-photo.org">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc">http://live.gnome.org/gtk-vnc</a> :|</div><div><br></div><div>__________________________________________________________________________</div><div>OpenStack Development Mailing List (not for usage questions)</div><div>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a></div><div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>