On 19/03/2019 12:13, Doug Hellmann wrote:
On Mar 19, 2019, at 5:45 AM, Thierry Carrez <thierry@openstack.org> 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 - 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
[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).
-- Thierry Carrez (ttx)
You make excellent points. I agree.
Doug
Yeap - this makes a lot of sense. - Graham