Open Stack

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/projects.yaml
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-repos.yaml

> 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.yaml

That decision was recorded in this resolution:

https://governance.openstack.org/tc/resolutions/20190322-namespace-unofficial-projects.html

(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-repository-retirement.html

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200520/a83ed05b/attachment.sig>