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) _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra