Open Stack

James E. Blair wrote:
> We've been discussing the thoroughly interesting problem of project
> taxonomy recently, and I'd like to describe what I think we've mostly
> decided we should do and make sure we're on the same page.  If we are,
> I'll invite the TC to weigh in and if they think we're completely wrong,
> we can work on some policy.
> 
> Move the following projects to the openstack-attic/ org (because they
> are no longer active projects though they had some degree of
> officialness about them at the time they were active):
> 
>  * openstack-dev/openstack-qa
>  * openstack/melange
>  * openstack/python-melangeclient
>  * openstack/openstack-chef
> 
> We should make these read-only as well.
> 
> Leave openstack-dev/sandbox where it is.  It's a useful tool for new
> openstack developers and third party CI systems -- it should be
> considered part of the openstack development process.

OK

> Move openstack/python-openstackclient to stackforge.  It's apparently a
> project without an official program.  (Incidentally, this makes me sad.)
> 
> Leave openstack/gantt where it is, but make it read-only.  The current
> state of development is considered a dead end, but there is likely to be
> a future attempt (and therefore future openstack/gantt repository).
> Rather than rename it and rename it back, or rename it to something like
> "openstack-attic/gant-mark-one", we think mothballing it and then
> replacing the entire branch with a merge commit for the second forklift
> attempt (like we did with keystone-lite) is the least silly option and
> actually faithfully represents development history.

On one hand I think openstack/python-openstackclient could temporarily
be left where it is until we have a clear idea of what its future is. On
the other moving it to stackforge could release enough energy for a
proper program request to be submitted. It's not a quick and easy
discussion though: there are competing approaches, the question of
whether all client libraries should also live under that program, and
the question of whether it should be lumped in a bigger end-user UX program.

-- 
Thierry Carrez (ttx)