> I think the only concern around moving spec freeze out would be that I > thought the original purpose of the spec freeze was to set expectations > early about what was approved and not approved instead of having folks > potentially in the situation where it's technically "maybe" for a large > chunk of the cycle. I'm not sure which most people prefer -- would you > rather know early and definitively whether your blueprint is > approved/not approved or would you rather have the opportunity to get > approval during a larger window in the cycle and not know definitively > early on? Can anyone else chime in here?
This is a fair point. Putting specs into runways doesn't imply (re)moving spec freeze IMO. It's just a way to get us using runways RIGHT NOW, so that folks with ready specs can get reviewed sooner, know whether they're approved sooner, write their code sooner, and get their *code* into an earlier runway. A spec in a runway would be treated like anything else: reviewers focus on it and the author needs to be available to respond quickly to feedback. I would expect the ratio of specs:code in runways to start off high and dwindle rapidly as we approach spec freeze. It's worth pointing out that there's not an expectation for people to work more/harder when runways are in play. Just that it increases the chances of more people looking at the same things at the same time; and allows us to bring focus to things that might otherwise languish in ignoreland. efried __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
