<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 2:51 AM, John Garbutt <span dir="ltr"><<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 5 March 2014 15:02, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br>
> Nova is now feature frozen for the Icehouse release.  Patches for<br>
> blueprints not already merged will need a feature freeze exception (FFE)<br>
> to be considered for Icehouse.<br>
><br>
> In addition to evaluation the request in terms of risks and benefits, I<br>
> would like to require that every FFE be sponsored by two members of<br>
> nova-core.  This is to ensure that there are reviewers willing to review<br>
> the code in a timely manner so that we can exclusively focus on bug<br>
> fixes as soon as possible.<br>
<br>
To help avoid adding too many FFE and not getting enough bug fixing done...<br>
<br>
I have a proposal to try and get many of the blueprints that just<br>
missed getting into Icehouse merged in early Juno, ideally before the<br>
Summit.<br></blockquote><div><br></div><div>Overall I really like this idea, and was toying around with something like it in my head the other day</div><div><br></div><div>It would be nice to just focus on the ones that have all there code up already, along with tracking number of outstanding patches.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For the interested, here are blueprints that met the proposal deadline<br>
but didn't make Icehouse-3:<br>
* API (v2) blueprints: 8<br>
* VMware: 7<br>
* Scheduler blueprints: 7  (two were partially completed in Icehouse)<br>
* Others: around another 7<br>
<br>
Making an effort to get these merged in Juno-1, and ideally before the<br>
summit, seems a fair thing to do.<br>
<br>
Once Juno opens, if submitters get their blueprint patches rebased and<br>
ready to review by two weeks before the summit, I propose we try to<br>
give them (where possible, and where it makes sense) at least medium<br>
priority, at least until after the summit.<br>
<br>
If we get too many takers, that might need some "refinement". However,<br>
looking at them, they all appear to be features that our users would<br>
really benefit from.<br>
<br>
This probably means, all non-"top priority" items would then get low<br>
priority in Juno-1. Currently tasks (at least the move to conductor<br>
parts), the scheduler split and objects, seem like they will be the<br>
other high priority items for Juno-1.<br>
<br>
This is all very rough, and subject to massive post-summit change, but<br>
looking at the ones with their priority set, gives a rough idea of<br>
what Juno-1 might look like:<br>
<a href="https://launchpad.net/nova/+milestone/next" target="_blank">https://launchpad.net/nova/+milestone/next</a><br>
<br>
Its just an idea. What do you all think?<br>
<br>
John<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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>
</blockquote></div><br></div></div>