[openstack-dev] [nova] Thoughts on things that don't make freeze cutoffs

Matt Riedemann mriedem at linux.vnet.ibm.com
Wed Jul 29 18:13:37 UTC 2015


We talked a bit about this at the nova mid-cycle last week but I can't 
say I completely remember all of the points made, since I feel like we 
talked ourselves into a circle that got us back to more or less 'the 
current specs and freeze process is the least of all evils so let's not 
change it'.

Tomorrow is the feature freeze for nova but there is interest from a few 
people in getting rbd snapshot support into liberty.  The code is up for 
review [1] but the spec is not approved [2].

With the process we have in place we can basically -2 this and say 
re-propose it for mitaka.

One thing mentioned at the mid-cycle was what if people reviewed the 
spec and approved it, but marked the blueprint for 'next' so it's not 
actually tracked for liberty, but if the blueprint is approved and 
people are willing to review the code, it could land in liberty.

The obvious downside here is the review burden, we have freeze deadlines 
in place to avoid a continual demand for feature review when we have 
bugs to fix before we release.  And it's not fair to the other people 
that already got their specs and blueprints approved with code up weeks 
or months ago but haven't had review attention and will just be deferred 
to another release. So we just end up with everyone being unhappy. :)

I'm trying to think of a way in which we could say, yeah, we've looked 
at the spec and this looks good, but don't expect it to land in the 
current release given other priorities and all of the other things we 
have actually agreed to review for this release (blueprint-wise). 
Basically your change goes on a backlog and come mitaka your blueprint 
could be moved from 'next' to the current release so it's part of the 
dashboard for tracking.

I'm not sure how that would work with re-proposing the spec, I assume 
that would stay the same, but at least then you can just slap the 
'previously-approved' tag in the spec commit and it's a fast path to 
re-approval.

This would also avoid the -2 on the code change which might prevent 
people from reviewing it thinking it's a waste of time.

The goal is to ease the frustration of people trying to get 
specs/blueprints approved after freeze but also balance that with an 
understanding that there are priorities and limits to the amount of time 
reviewers can spend on these things - so you know, don't come nagging in 
IRC every 5 minutes to review your thing which isn't planned for the 
current release. Is there a middle ground?

This is just spit-balling.  I really don't want this thread to turn into 
how the current process is ruining the world and killing babies, or how 
the review team isn't scaling and needs to be tripled or dissolved, etc 
etc, those ultimately don't seem to get anywhere constructive.

[1] https://review.openstack.org/#/c/205282/
[2] https://review.openstack.org/#/c/188244/

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-dev mailing list