On Tue, Aug 19, 2014 at 09:31:48PM +1200, Robert Collins wrote: > Hey everybody - https://wiki.openstack.org/wiki/TripleO/SpecReviews > seems pretty sane as we discussed at the last TripleO IRC meeting. > > I'd like to propose that we adopt it with the following tweak: > > 19:46:34 <lifeless> so I propose that +2 on a spec is a commitment to > review it over-and-above the core review responsibilities > 19:47:05 <lifeless> if its not important enough for a reviewer to do > that thats a pretty strong signal > 19:47:06 <dprince> lifeless: +1, I thought we already agreed to that > at the meetup > 19:47:17 <slagle> yea, sounds fine to me > 19:47:20 <bnemec> +1 > 19:47:30 <lifeless> dprince: it wasn't clear whether it was > part-of-responsibility, or additive, I'm proposing we make it clearly > additive > 19:47:52 <lifeless> and separately I think we need to make surfacing > reviews-for-themes a lot better > > That is - +1 on a spec review is 'sure, I like it', +2 is specifically > "I will review this *over and above* my core commitment" - the goal > here is to have some very gentle choke on concurrent WIP without > needing the transition to a managed pull workflow that Nova are > discussing - which we didn't have much support for during the meeting.
If it is considered to be a firm commitment to review the code, then people will have to be quite conservative when approving blueprints lest take accept too much work. It is hard to predict just how much work will be involved in the code review from the spec though, and even harder to predict /when/ during the dev cycle the code will be posted. I could approve 10 specs and think that's reasonable for the dev cycle, but if those 10 all have their code posted in Kilo-3, then I could be sitting idle with no features to review during Kilo-1/2 - time that could have been filled with specs I chose not to approve. And similarly I can still end up with far too much work during the Kilo3 phase to review. In terms of my efficiency as a reviewer it is really in my interests to approve more work than I can reasonably expect to review, and then prioritize the review activity at time stuff appears for review. Some stuff that's approved will ultimately miss out, but I think that is perfectly acceptable. People can improve their chances of not missing out by getting their code up for review sooner than their competitors which is a useful carrot IMHO. 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