[openstack-dev] [TripleO][Nova] Specs and approvals

Russell Bryant rbryant at redhat.com
Tue Aug 19 15:23:06 UTC 2014


On 08/19/2014 05:31 AM, 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.
> 
> Obviously, any core can -2 for any of the usual reasons - this motion
> is about opening up +A to the whole Tripleo core team on specs.
> 
> Reviewers, and other interested kibbitzers, please +1 / -1 as you feel fit :)

+1

I really like this.  In fact, I like it a lot more than the current
proposal for Nova.  I think the Nova team should consider this, as well.

It still rate limits code reviews by making core reviewers explicitly
commit to reviewing things.  This is like our previous attempt at
sponsoring blueprints, but the use of gerrit I think would make it more
successful.

It also addresses my primary concerns with the tensions between "group
will" and small groups no longer being able to self organize and push
things to completion without having to haggle through yet another process.

-- 
Russell Bryant



More information about the OpenStack-dev mailing list