On 19/03/19 5:45 AM, Thierry Carrez wrote:
Jim Rollenhagen wrote:
[...] 2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name.
3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams, though I think that's fairly rare.
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.
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
The line between these two is extremely blurry. (e.g. Monasca includes some of the same functionality as Aodh, but they're in different boxes.) I don't think it would be helpful to have them in separate namespaces.
- openstack-lifecyclemanagement/ to hold deployment recipes
I don't envy anyone having to type this.
- openstack-user/ for SDK and CLI
+1 for splitting this out, even if we don't split out the others, because in addition to sharing an audience with the others, client-side stuff also has another completely separate audience.
- openstack-adjacentenablers/ for adjacent tech bridges
I *really* don't envy anyone having to type this. Might something like openstack-bridges be better?
Plus: - openstack-libs/ to hold libraries and second-order dependencies
+1, it would be nice to get that stuff out of the openstack namespace, if only in recognition that some of it has other legitimate uses as well.
- 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 exists already, of course. Is there anything that you think should be in it but is not?
[1] https://openstack.org/openstack-map
Of those 3 options, (2) is a community-oriented view (openstack or not openstack), (3) is a developer-oriented view (organized by project teams, which really only matter to developers), and (4) is a user-oriented view (organized by what users are looking for).
My preference would be (4), otherwise (2).