Open Stack

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).
>