[openstack-dev] [Neutron] Gerrit permissions and Merge rights
Armando M.
armamig at gmail.com
Wed Oct 21 17:34:00 UTC 2015
On 21 October 2015 at 10:29, Kyle Mestery <mestery at mestery.com> wrote:
> On Wed, Oct 21, 2015 at 12:08 PM, Armando M. <armamig at gmail.com> wrote:
>
>>
>>
>> On 21 October 2015 at 09:53, Kyle Mestery <mestery at mestery.com> wrote:
>>
>>> On Wed, Oct 21, 2015 at 11:37 AM, Armando M. <armamig at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On 21 October 2015 at 04:12, Gal Sagie <gal.sagie at gmail.com> wrote:
>>>>
>>>>> Do we also want to consider Project Kuryr part of this?
>>>>>
>>>>
>>>> No, why would we?
>>>>
>>>>
>>> The reason to consider it is because Kuryr is a sub-project of Neutron,
>>> and they are doing their spec submissions following the Neutron guidelines.
>>> Adding the kuryr-core gerrit group to be on part with the *aas repos makes
>>> sense here. If other sub-projects (like L2FW, SFC, etc.) start doing spec
>>> reviews in the neutron-specs repository, then adding them makes sense too.
>>>
>>
>> I don't believe this is the road we set ourselves on when we started the
>> decomp/stadium. We wanted a clear separation of concerns and I don't see
>> how going down this path is going to help us achieve that.
>>
>> I don't see the grounds to have such an abrupt change in direction right
>> now, especially for the level of work that that would imply and the
>> pressure that would put on the drivers team. Anyone is free to review and
>> contribute where it matters for them, and location should not prevent them
>> from doing so.
>>
>>
> I was merely implying that since these projects are part of neutron, and
> they have specs, keeping them in one place makes sense. And by doing that,
> we'd need to give them +2 powers for their core reviewers. But, I'm fine
> with leaving things the way they are and having them put their specs in
> their devref. But we should update the devref in Neutron to reflect this,
> e.g. that we don't expect specs in neutron-specs for things outside
> [neutron, neutron-fwaas, neutron-lbaas, neutron-vpnaas].
>
>
IMO, it's pretty clear from here [1], which I revised in the context of
[2]. Not sure if there's anything else that's left to misunderstanding.
[1]
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#neutron-specs-core-reviewer-team
[2] https://review.openstack.org/#/c/237180/
>
>>>
>>>> We already started sending Kuryr spec to the Neutron repository and I
>>>>> think it would make sense to manage it
>>>>> as part of Neutron spec process.
>>>>>
>>>>
>>>> No, unless what you are asking are changes to the core. Do you have a
>>>> reference for me to look at?
>>>>
>>>>
>>> See above, perhaps I answered this for you.
>>>
>>
>>>
>>>>
>>>>> Any opinions on that?
>>>>>
>>>>> Gal.
>>>>>
>>>>> On Tue, Oct 20, 2015 at 11:10 PM, Armando M. <armamig at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi folks,
>>>>>>
>>>>>> During revision of the Neutron teams [1], we made clear that the
>>>>>> neutron-specs repo is to be targeted by specs for all the Neutron projects
>>>>>> (core + *-aas).
>>>>>>
>>>>>> For this reason I made sure that the neutron-specs-core team +2 right
>>>>>> was extended to all the core teams.
>>>>>>
>>>>>> Be mindful, use your +2 rights with care: if you are core on a *-aas
>>>>>> project, you should exercise that vote only for specs that pertain the
>>>>>> project you're core of.
>>>>>>
>>>>>> If I could use this email as a reminder also of the core hierarchy
>>>>>> and lieutenant system we switched to in Liberty ([3]): if you have been
>>>>>> made core by a lieutenant of a sub-system, please use your +2/+A only
>>>>>> within your area of comfort and reach out for help if in doubt.
>>>>>>
>>>>>> Reviews are always welcome though!
>>>>>>
>>>>>> Cheers,
>>>>>> Armando
>>>>>>
>>>>>> [1] https://review.openstack.org/#/c/237180/
>>>>>> [2] https://review.openstack.org/#/admin/groups/314,members
>>>>>> [3]
>>>>>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy
>>>>>>
>>>>>>
>>>>>> __________________________________________________________________________
>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>> Unsubscribe:
>>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best Regards ,
>>>>>
>>>>> The G.
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/0d04dd19/attachment.html>
More information about the OpenStack-dev
mailing list