Open Stack

On 7 March 2014 20:57, Joe Gordon <joe.gordon0 at gmail.com> wrote:
> 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
>> Summit.
>
>
> 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.

+1 only meant those that had all their patches up for review in time
for the feature freeze deadline.

It may seem restrictive, but that is§ already more blueprints than we
have merged in most Icehouse milestones.

>>
>>
>> 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:
>> https://launchpad.net/nova/+milestone/next
>>
>> Its just an idea. What do you all think?
>>
>> John
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>