Open Stack

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 :|