On Oct 22, 2015, at 2:47 AM, Kyle Mestery <mest...@mestery.com
<mailto:mest...@mestery.com>> wrote:
On Wed, Oct 21, 2015 at 12:34 PM, Armando M.<arma...@gmail.com
<mailto:arma...@gmail.com>>wrote:
On 21 October 2015 at 10:29, Kyle Mestery<mest...@mestery.com
<mailto:mest...@mestery.com>>wrote:
On Wed, Oct 21, 2015 at 12:08 PM, Armando
M.<arma...@gmail.com <mailto:arma...@gmail.com>>wrote:
On 21 October 2015 at 09:53, Kyle
Mestery<mest...@mestery.com
<mailto:mest...@mestery.com>>wrote:
On Wed, Oct 21, 2015 at 11:37 AM, Armando
M.<arma...@gmail.com <mailto:arma...@gmail.com>>wrote:
On 21 October 2015 at 04:12, Gal
Sagie<gal.sa...@gmail.com
<mailto:gal.sa...@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.
I think this [1] helps to make it 100% clearer, at least to me.
[1]https://review.openstack.org/238190
[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.<arma...@gmail.com
<mailto:arma...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org
<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
