<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>