'be considered to cleaned up’ i meant OR, not to. But I note that armax’s patch already clarified this, so I’ll go back to my jetlag stupor. :-)
Thanks, doug > On Oct 24, 2015, at 9:07 PM, Doug Wiegley <doug...@parksidesoftware.com> > wrote: > > As an alternative, to be considered to cleaned up, note that octavia, also a > neutron stadium project, puts its specs in its own repo, runs its own doc > jobs, etc. Pros and cons, but just pointing out that its out there. > > Thanks, > doug > > >> 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 <https://review.openstack.org/238190> >> >> [1] >> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#neutron-specs-core-reviewer-team >> >> <http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#neutron-specs-core-reviewer-team> >> [2] https://review.openstack.org/#/c/237180/ >> <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/ >> <https://review.openstack.org/#/c/237180/> >> [2] https://review.openstack.org/#/admin/groups/314,members >> <https://review.openstack.org/#/admin/groups/314,members> >> [3] >> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy >> >> <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 >> <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 >> <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 >> <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 >> <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 >> <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 >> <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 >> <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 >> <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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
