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