Update links in README

Change the outdated links to the latest links in README

Change-Id: Ieb73c9eb22c7875f1ba8155537bda967fbb7c0fe
XiaojueGuan 5 years ago
parent 32b6846ae6
commit a7f35d8a88

@ -194,7 +194,7 @@ set. Feel free to reach out to the VMT in public or in private.
Also, the VMT is an autonomous subgroup of the much larger `OpenStack Security
<http://governance.openstack.org/reference/projects/security.html>`_. They're a
<https://governance.openstack.org/tc/reference/projects/security.html>`_. They're a
knowledgeable bunch and quite responsive if you want to get their opinions or
help with security-related issues (vulnerabilities or otherwise).

@ -325,7 +325,7 @@ deprecation. Config items have `deprecation options supported by oslo.config
The deprecation process must follow the `standard deprecation requirements
In terms of neutron development, this means:
* A launchpad bug to track the deprecation.

@ -55,7 +55,7 @@ multiple constraints onto the software.
(otherwise newer services that require the newer schema would not work).
`More info on rolling upgrades in OpenStack
Those requirements are achieved in Neutron by:
@ -235,7 +235,7 @@ There are several upgrade related gotchas that should be tracked by reviewers.
First things first, a general advice to reviewers: make sure new code does not
violate requirements set by `global OpenStack deprecation policy
Now to specifics:

@ -134,7 +134,7 @@ However, you should add Neutron (Or any other project) to that list only if you
expect that a patch is needed to that repo in order to solve the bug.
It's also worth adding that some of these projects are part of the so
called Neutron `stadium <http://governance.openstack.org/reference/projects/neutron.html#deliverables-and-tags>`_.
called Neutron `stadium <https://governance.openstack.org/tc/reference/projects/neutron.html#deliverables-and-tags>`_.
Because of that, their release is managed centrally by the Neutron
release team; requests for releases need to be funnelled and screened
properly before they can happen. Release request process is described

@ -182,7 +182,7 @@ separate repositories with their own core reviewer teams. For each one of
these repositories in the following repository list, there is a core team
associated with it:
* `Neutron project team <http://governance.openstack.org/reference/projects/neutron.html>`_
* `Neutron project team <https://governance.openstack.org/tc/reference/projects/neutron.html>`_
These teams are also responsible for handling their own specs/RFEs/features if
they choose to use them. However, by choosing to be a part of the Neutron

@ -62,7 +62,7 @@ the Neutron umbrella is counterproductive.
These challenges led the Neutron team to find a better balance between autonomy
and consistency and lay down criteria that more clearly identify when a project
can be eligible for inclusion in the `Neutron governance <http://governance.openstack.org/reference/projects/neutron.html>`_.
can be eligible for inclusion in the `Neutron governance <https://governance.openstack.org/tc/reference/projects/neutron.html>`_.
This document describes these criteria, and document the steps involved to
maintain the integrity of the Stadium, and how to ensure this integrity be
@ -108,12 +108,12 @@ mature OpenStack projects:
information on how to do testing, please refer to the
:doc:`Neutron testing documentation </contributor/testing/testing>`.
* Good release footprint, according to the chosen `release model <http://governance.openstack.org/reference/tags/#release-management-tags>`_.
* Good release footprint, according to the chosen `release model <https://governance.openstack.org/tc/reference/tags/#release-management-tags>`_.
* Adherence to deprecation and `stable backports policies <http://governance.openstack.org/reference/tags/#stable-maintenance-tags>`_.
* Adherence to deprecation and `stable backports policies <https://governance.openstack.org/tc/reference/tags/#stable-maintenance-tags>`_.
* Demonstrated ability to do `upgrades <http://governance.openstack.org/reference/tags/assert_supports-upgrade.html>`_
and/or `rolling upgrades <http://governance.openstack.org/reference/tags/assert_supports-rolling-upgrade.html>`_,
* Demonstrated ability to do `upgrades <https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html>`_
and/or `rolling upgrades <https://governance.openstack.org/tc/reference/tags/assert_supports-rolling-upgrade.html>`_,
where applicable. This means having grenade support on top of the CI
coverage as described above.
@ -267,7 +267,7 @@ Checklist
Once, everything is set up and your project is released, make sure
you see an entry on the release page (e.g. `Pike <http://releases.openstack.org/pike/index.html#other-projects>`_.
Make sure you release according to the project declared release
`model <http://governance.openstack.org/reference/projects/neutron.html#deliverables-and-tags>`_.
`model <https://governance.openstack.org/tc/reference/projects/neutron.html#deliverables-and-tags>`_.
* How to port OpenStack Client over to python-neutronclient: client
API bindings and client command line interface support must be

@ -18,7 +18,7 @@ Neutron Stadium
This section contains information on policies and procedures for the so called
Neutron Stadium. The Neutron Stadium is the list of projects that show up in the
OpenStack `Governance Document <http://governance.openstack.org/reference/projects/neutron.html>`_.
OpenStack `Governance Document <https://governance.openstack.org/tc/reference/projects/neutron.html>`_.
The list includes projects that the Neutron PTL and core team are directly
involved in, and manage on a day to day basis. To do so, the PTL and team