On Thu, Mar 27, 2014 at 1:10 PM, Thierry Carrez <thie...@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 _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra