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. -- 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