Open Stack

On Tue, Mar 19, 2019 at 5:50 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).
>

This makes sense in general, but we're talking about git repositories
and only git repositories.

Who looks for git repositories most often, users or developers? :)

(Sorry for the spam, ttx, reply button got me again)

// jim


>
> My preference would be (4), otherwise (2).
>
> --
> Thierry Carrez (ttx)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190319/2c8fbfb1/attachment.html>