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 <[email protected]> > Dougal Matthews <[email protected]>
+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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
