Open Stack

On 19/03/2019 12:13, Doug Hellmann wrote:
> 
> 
>> On Mar 19, 2019, at 5:45 AM, Thierry Carrez <thierry at 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

> 
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190319/cbf50ddd/attachment.sig>