On Thu, Aug 28, 2014 at 01:04:57AM +0000, Dugger, Donald D wrote: > I'll try and not whine about my pet project but I do think there > is a problem here. For the Gantt project to split out the scheduler > there is a crucial BP that needs to be implemented ( > https://review.openstack.org/#/c/89893/ ) and, unfortunately, the > BP has been rejected and we'll have to try again for Kilo. My question > is did we do something wrong or is the process broken? > > Note that we originally proposed the BP on 4/23/14, went through 10 > iterations to the final version on 7/25/14 and the final version got > three +1s and a +2 by 8/5. Unfortunately, even after reaching out > to specific people, we didn't get the second +2, hence the rejection.
I see at that it did not even get one +2 at the time of the feature proposal approval freeze. You then successfully requested an exception and after a couple more minor updates got a +2 from John but from no one else. I do think this shows a flaw in our (core teams) handling of the blueprint. When we agreed upon the freeze exception, that should have included a firm commitment for a least 2 core devs to review it. IOW I think it is reasonable to say that either your feature should have ended up with two +2s and +A, or you should have seen a -1 from another core dev. I don't think it is acceptable that after the exception was approved it only got feedback from one core dev. I actually thought that when approving exceptions, we always got 2 cores to agree to review the item to avoid this, so I'm not sure why we failed here. > I understand that reviews are a burden and very hard but it seems > wrong that a BP with multiple positive reviews and no negative > reviews is dropped because of what looks like indifference. Given > that there is still time to review the actual code patches it seems > like there should be a simpler way to get a BP approved. Without > an approved BP it's difficult to even start the coding process. > > I see 2 possibilities here: > > > 1) This is an isolated case specific to this BP. If so, > there's no need to change the procedures but I would like to > know what we should be doing differently. We got a +2 review > on 8/4 and then silence for 3 weeks. > > 2) This is a process problem that other people encounter. > Maybe there are times when silence means assent. Something > like a BP with multiple +1s and at least one +2 should > automatically be accepted if no one reviews it 2 weeks after > the +2 is given. My two thoughts are - When we approve something for exception should actively monitor progress of review to ensure it gets the neccessary attention to either approve or reject it. It makes no sense to approve an exception and then let it lie silently waiting for weeks with no attention. I'd expect that any time exceptions are approved we should babysit them and actively review their status in the weekly meeting to ensure they are followed up on. - Core reviewers should prioritize reviews of things which already have a +2 on them. I wrote about this in the context of code reviews last week, but all my points apply equally to spec reviews I believe. http://lists.openstack.org/pipermail/openstack-dev/2014-August/043657.html Also note that in Kilo the process will be slightly less heavyweight in that we're going to try allow some features changes into tree without first requiring a spec/blueprint to be written. I can't say offhand whether this particular feature would have qualifying for the lighter process, but in general by reducing need for specs for the more trivial items, we'll have more time available for review of things which do require specs. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev