Open Stack

On 03/06/2014 05:51 AM, John Garbutt 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.
> 
> 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?

I think it's generally a good approach. I'll just caution that most of
the core review team is burnt out hard by the end of the release, and
really does need a breather. There is plenty of prep that needs to
happen to summit, and it provides a pretty solid recharge.

In the past I think the biggest issue you saw blueprints miss two cycles
in a row is their authors weren't working on them until milestone 2. So
anything that's open and ready to go in Juno.

That being said, importance isn't a FIFO. And with limited review time I
question a ton of scheduler blueprints at the same time we're talking
about a scheduler split. Because like it seems like it makes both things
slower to try them at the same time (as there are a limited number of
people here). So I think at least in this case scheduler really should
be split then improve, or improve then split, and everyone interested in
either side of that equation needs to be helping on both sides.

Otherwise I think we'll see another do-over on the split again at the
end of the Juno cycle.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140306/8cb3c251/attachment.pgp>