[openstack-dev] [Nova] Proposal to merge blueprints that just missed Icehouse-3 in early Juno-1
joe.gordon0 at gmail.com
Fri Mar 7 20:57:15 UTC 2014
On Thu, Mar 6, 2014 at 2:51 AM, John Garbutt <john at johngarbutt.com> wrote:
> On 5 March 2014 15:02, Russell Bryant <rbryant at redhat.com> wrote:
> > Nova is now feature frozen for the Icehouse release. Patches for
> > blueprints not already merged will need a feature freeze exception (FFE)
> > to be considered for Icehouse.
> > In addition to evaluation the request in terms of risks and benefits, I
> > would like to require that every FFE be sponsored by two members of
> > nova-core. This is to ensure that there are reviewers willing to review
> > the code in a timely manner so that we can exclusively focus on bug
> > fixes as soon as possible.
> To help avoid adding too many FFE and not getting enough bug fixing done...
> I have a proposal to try and get many of the blueprints that just
> missed getting into Icehouse merged in early Juno, ideally before the
Overall I really like this idea, and was toying around with something like
it in my head the other day
It would be nice to just focus on the ones that have all there code up
already, along with tracking number of outstanding patches.
> For the interested, here are blueprints that met the proposal deadline
> but didn't make Icehouse-3:
> * API (v2) blueprints: 8
> * VMware: 7
> * Scheduler blueprints: 7 (two were partially completed in Icehouse)
> * Others: around another 7
> Making an effort to get these merged in Juno-1, and ideally before the
> summit, seems a fair thing to do.
> Once Juno opens, if submitters get their blueprint patches rebased and
> ready to review by two weeks before the summit, I propose we try to
> give them (where possible, and where it makes sense) at least medium
> priority, at least until after the summit.
> If we get too many takers, that might need some "refinement". However,
> looking at them, they all appear to be features that our users would
> really benefit from.
> This probably means, all non-"top priority" items would then get low
> priority in Juno-1. Currently tasks (at least the move to conductor
> parts), the scheduler split and objects, seem like they will be the
> other high priority items for Juno-1.
> This is all very rough, and subject to massive post-summit change, but
> looking at the ones with their priority set, gives a rough idea of
> what Juno-1 might look like:
> Its just an idea. What do you all think?
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev