> On Apr 23, 2015, at 1:42 PM, Russell Bryant <rbry...@redhat.com> wrote: > > On 04/23/2015 03:23 PM, Kyle Mestery wrote: >> On Thu, Apr 23, 2015 at 2:18 PM, Doug Wiegley >> <doug...@parksidesoftware.com <mailto:doug...@parksidesoftware.com>> wrote: >> >> >>> On Apr 23, 2015, at 11:57 AM, Russell Bryant <rbry...@redhat.com >> <mailto:rbry...@redhat.com>> wrote: >>> >>> On 04/23/2015 01:19 PM, Armando M. wrote: >>>> >>>> >>>> On 23 April 2015 at 09:58, Russell Bryant <rbry...@redhat.com >> <mailto:rbry...@redhat.com> >>>> <mailto:rbry...@redhat.com <mailto:rbry...@redhat.com>>> wrote: >>>> >>>> On 04/23/2015 12:14 PM, Armando M. wrote: >>>>> >>>>> >>>>> On 23 April 2015 at 07:32, Russell Bryant <rbry...@redhat.com >> <mailto:rbry...@redhat.com> <mailto:rbry...@redhat.com >> <mailto:rbry...@redhat.com>> >>>>> <mailto:rbry...@redhat.com <mailto:rbry...@redhat.com> >> <mailto:rbry...@redhat.com <mailto:rbry...@redhat.com>>>> wrote: >>>>> >>>>> On 04/22/2015 10:33 PM, Armando M. wrote: >>>>>> >>>>>> Would it make sense to capture these projects as simply >>>>>> 'affiliated', ie. with a loose relationship to Neutron, >>>>> because >>>>>> they use/integrate with Neutron in some form or >>>> another (e.g. >>>>>> having 3rd-party, extending-api, >>>> integrating-via-plugin-model, >>>>>> etc)? Then we could simply consider extending the >>>>> projects.yaml >>>>>> to capture this new concept (for Neutron or any >>>> other project) >>>>>> once we defined its ontology. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> >>>>>> That seems interesting, but given the communities stated >>>> goals >>>>>> around Big Tent, it seems to me like affiliation or not, >>>> adding >>>>>> these under the Neutron tent, inside the larger >>>> OpenStack Bigger >>>>>> Tent, would be a good thing. >>>>>> >>>>>> Thanks, >>>>>> Kyle >>>>>> >>>>>> >>>>>> >>>>>> Thanks for clearing some of the questions I raised. I should >>>>> stress the >>>>>> fact that I welcome the idea of finding a more sensible home >>>> for these >>>>>> projects in light of the big tent developments, but it seems >>>> like >>>>> we're >>>>>> still pouring down the foundations. I'd rather get us to a >>>> point where >>>>>> the landscape is clear, and the dust settled. That would help us >>>>> make a >>>>>> more informed decision compared to the one we can make right >>>> now. >>>>> >>>>> Can you be a bit more specific about what's not clear and >>>> would help >>>>> make you feel more informed? >>>>> >>>>> >>>>> I am not clear on how we make a decision, as to which project >>>> belongs or >>>>> doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however >> we end >>>>> up calling it :) >>>> >>>> OK, that's fine. Figuring that out is the next step if folks >> agree with >>>> Neutron as the home for networking-foo repos. I'm happy to >> write up a >>>> strawman proposal for inclusion criteria and a set of expectations >>>> around responsibilities and communication. >>>> >>>> >>>> What about the other Neutron related ones that didn't strictly follow >>>> the networking- prefix in the name, would the naming convention >> be one >>>> of the criteria? I look forward to your proposal. >>> >>> Good question. I think consistency is good, especially when there are >>> so many of them. It helps make it clear that they're all >> following some >>> sort of pattern. Luckily we do have a way to get repos renamed if >> needed. >> >> There is one existing project, stackforge/octavia, which is quite >> active and has used its codename extensively. Suggested naming I’d >> be ok with, but enforced naming seems… confining. > > To be honest, I really don't care about the names. All it takes is some > pretty easy docs to help people figure out what things are and where > they live. Making it a recommendation is fine with me. > >> >> If we've reached the point where we're arguing about naming, dos this >> mean we've built consensus on the "yes, it makes sense for these to live >> under Neutron" argument? > > Ha. I figured I'd give it at least another day before stirring up more > debate with a proposal around criteria / responsibilities / expectations.
Quick, someone invoke Godwin’s law, and then let’s ship this thing. doug > > -- > Russell Bryant > > __________________________________________________________________________ > 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 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