On 02/04/2016 08:33 AM, Thierry Carrez wrote:
Hayes, Graham wrote:
On 04/02/2016 13:24, Doug Hellmann wrote:
Excerpts from Hayes, Graham's message of 2016-02-04 12:54:56 +0000:
On 04/02/2016 11:40, Sean Dague wrote:
2) Have a registry of "common" names.
Upside, we can safely use common names everywhere and not fear
collision down the road.
Downside, yet another contention point.
A registry would clearly be under TC administration, though all the
heavy lifting might be handed over to the API working group. I still
imagine collision around some areas might be contentious.
++ to a central registry. It could easily be added to the projects.yaml
file, and is a single source of truth.
Although I realized that the projects.yaml file only includes official
projects right now, which would mean new projects wouldn't have a place
to register terms. Maybe that's a feature?
That is a good point - should we be registering terms for non tent
projects? Or do projects get terms when they get accepted into the tent?
I don't see why we would register terms for non-official projects. I
don't see under what authority we would do that, or where it would end.
So yes, that's a feature.
i have a question about this, as new, non-official, projects start to
spin up there will be questions about the naming conventions they will
use within the project as to headers and the like. given that the
current guidance trend in the api-wg is towards using "service type" in
these cases, how would these projects proceed?
(i'm not suggesting these projects should be registered, just curious)
I think solution 2 is the best. To avoid too much contention, that can
easily be delegated to the API WG, and escalated to the TC for
resolution only in case of conflict between projects (or between a
project and the API WG).
i'm +1 for solution 2 as well. as to the api-wg participation in the
name registration side of things , i don't have an objection but i am
very curious to hear Everett's and Chris' opinions.
regards,
mike
__________________________________________________________________________
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
