On Fri, Aug 8, 2014 at 2:06 AM, Thierry Carrez <thie...@openstack.org> wrote: > > Michael Still wrote: > > [...] I think an implied side effect of > > the runway system is that nova-drivers would -2 blueprint reviews > > which were not occupying a slot. > > > > (If we start doing more -2's I think we will need to explore how to > > not block on someone with -2's taking a vacation. Some sort of role > > account perhaps). > > Ideally CodeReview-2s should be kept for blocking code reviews on > technical grounds, not procedural grounds. For example it always feels > weird to CodeReview-2 all feature patch reviews on Feature Freeze day -- > that CodeReview-2 really doesn't have the same meaning as a traditional > CodeReview-2. > > For those "procedural blocks" (feature freeze, waiting for runway > room...), it might be interesting to introduce a specific score > (Workflow-2 perhaps) that drivers could set. That would not prevent code > review from happening, that would just clearly express that this is not > ready to land for release cycle / organizational reasons. > > Thoughts? >
+1 In addition to distinguishing between procedural and technical blocks, this sounds like it will also solve the current problem when a core reviewer has gone on vacation after blocking something for procedural reasons. -Deva _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev