On 9/4/2014 4:21 AM, Day, Phil wrote:

One final note: the specs referenced above didn't get approved until
Spec Freeze, which seemed to leave me with less time to implement
things.  In fact, it seemed that a lot of specs didn't get approved
until spec freeze.  Perhaps if we had more staggered approval of
specs, we'd have more staggered submission of patches, and thus less of a
sudden influx of patches in the couple weeks before feature proposal

Yeah I think the specs were getting approved too late into the cycle, I was
actually surprised at how far out the schedules were going in allowing things
in and then allowing exceptions after that.

Hopefully the ideas around priorities/slots/runways will help stagger some of
this also.

I think there is a problem with the pattern that seemed to emerge in June where 
the J.1 period was taken up with spec review  (a lot of good reviews happened 
early in that period, but the approvals kind of came in a lump at the end)  
meaning that the implementation work itself only seemed to really kick in 
during J.2 - and not surprisingly given the complexity of some of the changes 
ran late into J.3.

We also has previously noted didn’t do any prioritization between those specs 
that were approved - so it was always going to be a race to who managed to get 
code up for review first.

It kind of feels to me as if the ideal model would be if we were doing spec 
review for K now (i.e during the FF / stabilization period) so that we hit 
Paris with a lot of the input already registered and a clear idea of the range  
of things folks want to do.    We shouldn't really have to ask for session 
suggestions for the summit  - they should be something that can be extracted 
from the proposed specs (maybe we do voting across the specs or something like 
that).    In that way the summit would be able to confirm the list of specs for 
K and the priority order.

With the current state of the review queue maybe we can’t quite hit this 
pattern for K, but would be worth aspiring to for I ?


OpenStack-dev mailing list

I like the idea of having our ducks somewhat in a row for the summit so we can hash out details in design sessions on high-priority specs and reserve time for figuring out what the priorities are. I think that would go a long way in fixing some of the frustrations in the other thread about the mid-cycle meetups being the place where blueprint issues are hashed out rather than the summit, and the design sessions at the summit not feeling productive.

But as noted, there is also a feeling right now of focusing on Juno to get that out the door before anyone starts getting distracted with reviewing Kilo specs. And I suppose once Juno is finished no one is going to want to talk about Kilo for awhile due to burnout.



Matt Riedemann

OpenStack-dev mailing list

Reply via email to