On 2020-05-20 23:45:17 +0200 (+0200), Slawek Kaplonski wrote:
Actually I'm not really sure what are the criteria of what should be in the "openstack/" and what in "x/" namespace. I know that in "openstack/" should be an official OpenStack projects but how to really be sure what is such official project and what no, I don't know.
"Officially part of OpenStack" in this case means it's listed in https://opendev.org/openstack/governance/src/branch/master/reference/project... at the time it was published, but also inclusion here has been considered sufficient for carrying the OpenStack name in similar ways: https://opendev.org/openstack/governance/src/branch/master/reference/sigs-re...
Speaking about those projects mentioned in the thread, networking-mlnx and vmware-nsx are both in the "x/" namespace but networking-l2gw is in the "openstack/" namespace. None of them is Neutron stadium project. There is also many other projects with "networking-" in the name in the "openstack/" namespace. For example:
networking-baremetal networking-generic-switch
which Ironic team is taking care of. But we have also projects like:
networking-onos networking-calico
and probably others. Those projects are not in deliverables in https://opendev.org/openstack/releases/src/branch/master (at least not for Train or Ussuri releases). So should we keep them in "openstack/" namespace or move to "x/"? [...]
During the great namespace migration, we did not rename(space) any repositories listed in the two files I mentioned above or any which were formerly part of OpenStack as evidenced by inclusion in this file: https://opendev.org/openstack/governance/src/branch/master/reference/legacy.... That decision was recorded in this resolution: https://governance.openstack.org/tc/resolutions/20190322-namespace-unofficia... (Worth noting, the "unknown/" namespace mentioned there was a placeholder, and "x/" is what the OpenDev sysadmins ultimately chose to use instead.) We announced via another resolution that any projects which were once but no longer part of OpenStack had until the end of the Train cycle to pick a new namespace for themselves: https://governance.openstack.org/tc/resolutions/20190711-mandatory-repositor... I guess the question is what to do about artifacts generated for stable branches of repositories which were deliverables for earlier OpenStack coordinated releases. My take is that we've already got a concept of "partial retirement" where a project is deprecated but still receives stable branch releases for some period of time thereafter. Taking the mandatory retirement resolution into account, I think that means the best fit for a workflow is to fork continued development to another namespace outside "openstack/" namespace (whether that's "x/" or something new), and follow the current partial retirement precedent for the original copy which remains in the "openstack/" namespace. I agree though, this is a tough question with obvious complexities for all possible solutions. -- Jeremy Stanley