IMHO the key difference between (2) and (3) is that it will be much harder to see which projects are part of OpenStack with (3).
Historically we've seen a lot of confusion with a single "openstack/" namespace, with things claiming to be OpenStack projects while not being produced by the OpenStack community under the 4 opens.
The move to opendev gives us an opportunity to move things that are not OpenStack out of the "openstack/" namespace, into their own namespaces. But if at the same time we also move OpenStack components into their own project-level namespaces, then the confusion as to what is a part of openstack and what is not will stay.
Do you have a definition for "what is OpenStack?" :)
So between (2) and (3) I'd really prefer if we did (2).
4) ??
I'd propose this:
4) Create several namespaces to match the OpenStack map[1] buckets:
- openstack/ to hold first-level components in the central box - openstack-operations/ to hold operational tooling from the rights box - openstack-lifecyclemanagement/ to hold deployment recipes - openstack-user/ for SDK and CLI - openstack-adjacentenablers/ for adjacent tech bridges
Plus: - openstack-libs/ to hold libraries and second-order dependencies - openstack-dev/ for all repositories that we end up creating in order to get things done but have otherwise no relationship with the end product
This makes a lot of sense to me to match the map. I do kind of like having each team with their own namespace though. There are several components this community makes that could have use outside of OpenStack, but with the way it is today, others see it as just an OpenStack thing and dismiss the idea without much thought. Separating out into team namespaces would at least give some level of conceptual independence to these deliverables that could ease that. But that said, I think this option 4 is very logical and would organize things well to fit into how things have been laid out in the map, so there's a lot of value to that. Sean