Re: [openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

[James Slagle]

Hi, It's been a week, and I've heard no objections this proposal:

>> Specifically, the folks I'm proposing are:
>> Brad P. Crochet 
>> Dougal Matthews 

>> - keep just 1 tripleo acl, and add additional folks there, with a good
>> faith agreement not to +/-2,+A code that is not from the 2 client
>> repos.

I've added them to the core team. Thanks!



-- 
-- James Slagle
--

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

[Jay Dobies]

On 09/10/2015 10:06 AM, James Slagle wrote:

TripleO has added a few new repositories, one of which is
python-tripleoclient[1], the former python-rdomanager-oscplugin.

With the additional repositories, there is an additional review burden
on our core reviewers. There is also the fact that folks who have been
working on the client code for a while when it was only part of RDO
are not TripleO core reviewers.

I think we could help with the additional burden of reviews if we made
two of those people core on python-tripleoclient and tripleo-common
now.

Specifically, the folks I'm proposing are:
Brad P. Crochet 
Dougal Matthews 


+1 to both. I've seen a lot of Dougal's reviews and his Python knowledge 
is excellent.



The options I see are:
- keep just 1 tripleo acl, and add additional folks there, with a good
faith agreement not to +/-2,+A code that is not from the 2 client
repos.


+1 to this. I feel like it encourages cross pollination into other 
tripleo repos (we could use the eyes on THT) without having to jump 
through extra hoops as their involvement with them increases.



- create a new gerrit acl in project-config for just these 2 client
repos, and add folks there as needed. the new acl would also contain
the existing acl for tripleo core reviewers
- neither of the above options - don't add these individuals to any
TripleO core team at this time.

The first is what was more or less done when Tuskar was brought under
the TripleO umbrella to avoid splitting the core teams, and it's the
option I'd prefer.

TripleO cores, please reply here with your vote from the above
options. Or, if you have other ideas, you can share those as well :)

[1] https://review.openstack.org/#/c/215186/



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

[Ben Nemec]

On 09/10/2015 09:06 AM, James Slagle wrote:
> TripleO has added a few new repositories, one of which is
> python-tripleoclient[1], the former python-rdomanager-oscplugin.
> 
> With the additional repositories, there is an additional review burden
> on our core reviewers. There is also the fact that folks who have been
> working on the client code for a while when it was only part of RDO
> are not TripleO core reviewers.
> 
> I think we could help with the additional burden of reviews if we made
> two of those people core on python-tripleoclient and tripleo-common
> now.
> 
> Specifically, the folks I'm proposing are:
> Brad P. Crochet 
> Dougal Matthews  

+1 to both

> 
> The options I see are:
> - keep just 1 tripleo acl, and add additional folks there, with a good
> faith agreement not to +/-2,+A code that is not from the 2 client
> repos.

+1 to this.

Personally I would hope that anyone who is a core has the necessary
judgment to not +2 things they don't understand, regardless of project
(and vice versa; Brad and Dougal obviously understand TripleO from their
work on the client, so if they +2 a simple patch in another project I'm
not inclined to take them to the woodshed :-).  "TripleO" is a broad
enough thing that there are areas where all of the cores are going to be
weaker or stronger.  I'd rather not have to maintain half a dozen
separate ACL's just to enforce something that should be common sense.

> - create a new gerrit acl in project-config for just these 2 client
> repos, and add folks there as needed. the new acl would also contain
> the existing acl for tripleo core reviewers
> - neither of the above options - don't add these individuals to any
> TripleO core team at this time.
> 
> The first is what was more or less done when Tuskar was brought under
> the TripleO umbrella to avoid splitting the core teams, and it's the
> option I'd prefer.
> 
> TripleO cores, please reply here with your vote from the above
> options. Or, if you have other ideas, you can share those as well :)
> 
> [1] https://review.openstack.org/#/c/215186/
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

[James Slagle]

TripleO has added a few new repositories, one of which is
python-tripleoclient[1], the former python-rdomanager-oscplugin.

With the additional repositories, there is an additional review burden
on our core reviewers. There is also the fact that folks who have been
working on the client code for a while when it was only part of RDO
are not TripleO core reviewers.

I think we could help with the additional burden of reviews if we made
two of those people core on python-tripleoclient and tripleo-common
now.

Specifically, the folks I'm proposing are:
Brad P. Crochet 
Dougal Matthews 

The options I see are:
- keep just 1 tripleo acl, and add additional folks there, with a good
faith agreement not to +/-2,+A code that is not from the 2 client
repos.
- create a new gerrit acl in project-config for just these 2 client
repos, and add folks there as needed. the new acl would also contain
the existing acl for tripleo core reviewers
- neither of the above options - don't add these individuals to any
TripleO core team at this time.

The first is what was more or less done when Tuskar was brought under
the TripleO umbrella to avoid splitting the core teams, and it's the
option I'd prefer.

TripleO cores, please reply here with your vote from the above
options. Or, if you have other ideas, you can share those as well :)

[1] https://review.openstack.org/#/c/215186/

-- 
-- James Slagle
--

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

[Derek Higgins]

On 10/09/15 15:06, James Slagle wrote:

TripleO has added a few new repositories, one of which is
python-tripleoclient[1], the former python-rdomanager-oscplugin.

With the additional repositories, there is an additional review burden
on our core reviewers. There is also the fact that folks who have been
working on the client code for a while when it was only part of RDO
are not TripleO core reviewers.

I think we could help with the additional burden of reviews if we made
two of those people core on python-tripleoclient and tripleo-common
now.

Specifically, the folks I'm proposing are:
Brad P. Crochet 
Dougal Matthews 

The options I see are:
- keep just 1 tripleo acl, and add additional folks there, with a good
faith agreement not to +/-2,+A code that is not from the 2 client
repos.


+1 to doing this, but I would reword the good faith aggreement to "not 
to +/-2,+A code that they are not comfortable/familiar with", in other 
words the same agreement I would expect from any other core. In the same 
way I'll not be adding +2 on tripleoclient code until(if) I know with 
reasonable confidence I'm not doing something stupid.




- create a new gerrit acl in project-config for just these 2 client
repos, and add folks there as needed. the new acl would also contain
the existing acl for tripleo core reviewers
- neither of the above options - don't add these individuals to any
TripleO core team at this time.

The first is what was more or less done when Tuskar was brought under
the TripleO umbrella to avoid splitting the core teams, and it's the
option I'd prefer.

TripleO cores, please reply here with your vote from the above
options. Or, if you have other ideas, you can share those as well :)

[1] https://review.openstack.org/#/c/215186/



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

[Steven Hardy]

On Thu, Sep 10, 2015 at 10:06:31AM -0400, James Slagle wrote:
> TripleO has added a few new repositories, one of which is
> python-tripleoclient[1], the former python-rdomanager-oscplugin.
> 
> With the additional repositories, there is an additional review burden
> on our core reviewers. There is also the fact that folks who have been
> working on the client code for a while when it was only part of RDO
> are not TripleO core reviewers.
> 
> I think we could help with the additional burden of reviews if we made
> two of those people core on python-tripleoclient and tripleo-common
> now.
> 
> Specifically, the folks I'm proposing are:
> Brad P. Crochet 
> Dougal Matthews 

+1 to both!

> The options I see are:
> - keep just 1 tripleo acl, and add additional folks there, with a good
> faith agreement not to +/-2,+A code that is not from the 2 client
> repos.

+1, as others have mentioned I think a common-sense agreement here will be fine 
:)

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev