Open Stack

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)