Open Stack

On Thu, Mar 27, 2014 at 1:10 PM, Thierry Carrez <thierry at openstack.org> wrote:
> 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)


During the last couple of months we significantly reduced number of Murano
repositories. We will mark the following repos as deprecated:
* stackforge/murano-common
* stackforge/murano-repository
* stackforge/murano-metadataclient
* stackforge/murano-conductor

Two or three more repositories will be deprecated a little bit later.

Murano is not the only project which has deprecated repositories. There are
several abandoned repositories, for instance MRaaS [0]. Maybe it's about time
to create something similar to Apache Attic [1] and move these  repos outside
of Stackforge?

[0] http://git.openstack.org/cgit/stackforge/MRaaS/
[1] https://attic.apache.org/

--
Ruslan