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

2014-08-25 Thread Jay Dobies
I was on vacation last week and am late to the discussion, but I'm +1 
for the idea.


On 08/19/2014 02:08 PM, Joe Gordon wrote:




On Tue, Aug 19, 2014 at 8:23 AM, Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com wrote:

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.


Nova and tripleo are at different points in there lifecycle just look at
tripleo-specs [0] vs nova-specs [1]. TripleO has 11 specs and nova has
80+, TripleO has 22 cores and nova has 21 cores.  AFAIK none of the
tripleo specs are vendor specific, while a good chunk of nova ones are.
I don't think there is a one size fits all solution here.


[0] http://specs.openstack.org/openstack/tripleo-specs/
[1] http://specs.openstack.org/openstack/nova-specs/


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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-19 Thread Russell Bryant
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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-19 Thread Jay Pipes

On 08/19/2014 11:23 AM, Russell Bryant wrote:

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.


+1

Me likee.
-jay


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-19 Thread Joe Gordon
On Tue, Aug 19, 2014 at 8:23 AM, Russell Bryant rbry...@redhat.com wrote:

 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.


Nova and tripleo are at different points in there lifecycle just look at
tripleo-specs [0] vs nova-specs [1]. TripleO has 11 specs and nova has 80+,
TripleO has 22 cores and nova has 21 cores.  AFAIK none of the tripleo
specs are vendor specific, while a good chunk of nova ones are. I don't
think there is a one size fits all solution here.


[0] http://specs.openstack.org/openstack/tripleo-specs/
[1] http://specs.openstack.org/openstack/nova-specs/


 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

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev