openstack
/
nova
Code Issues Proposed changes

Merge "Update doc/source/process.rst"

This commit is contained in:
Jenkins 2017-04-26 12:29:51 +00:00 committed by Gerrit Code Review
parent d622bad0cb f332a0476f
commit 2658bd30f8
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
doc/source/process.rst
View File

@ -36,8 +36,8 @@ If you are new to Nova, please read this first: :ref:`getting_involved`.
Dates overview Dates overview
============== ==============
For Ocata, please see: For Pike, please see:
https://wiki.openstack.org/wiki/Nova/Ocata_Release_Schedule https://wiki.openstack.org/wiki/Nova/Pike_Release_Schedule
.. note: Throughout this document any link which references the name of a .. note: Throughout this document any link which references the name of a
release cycle in the link can usually be changed to the name of the release cycle in the link can usually be changed to the name of the
@ -98,10 +98,10 @@ Why we have a Spec Freeze:
bounding is a useful way to limit the number of submissions bounding is a useful way to limit the number of submissions
By the freeze date, we expect all blueprints that will be approved for the By the freeze date, we expect all blueprints that will be approved for the
cycle to be listed on launchpad and all relevant specs to be merged. For Ocata cycle to be listed on launchpad and all relevant specs to be merged. For Pike,
blueprints can be found at https://blueprints.launchpad.net/nova/ocata and blueprints can be found at https://blueprints.launchpad.net/nova/pike and
specs at specs at
http://specs.openstack.org/openstack/nova-specs/specs/ocata/index.html https://specs.openstack.org/openstack/nova-specs/specs/pike/index.html
Starting with Liberty, we are keeping a backlog open for submission at all Starting with Liberty, we are keeping a backlog open for submission at all
times. Note: the focus is on accepting and agreeing problem statements times. Note: the focus is on accepting and agreeing problem statements
@ -125,7 +125,7 @@ Non-priority Feature Freeze
This is a Nova specific process. This is a Nova specific process.
This only applies to low priority blueprints in this list: This only applies to low priority blueprints in this list:
https://blueprints.launchpad.net/nova/ocata https://blueprints.launchpad.net/nova/pike
We currently have a very finite amount of review bandwidth. In order to We currently have a very finite amount of review bandwidth. In order to
make code review time for the agreed community wide priorities, we have make code review time for the agreed community wide priorities, we have
@ -151,7 +151,7 @@ http://lists.openstack.org/pipermail/openstack-dev/2015-July/070920.html
Exception process: Exception process:
- Please add request in here: - Please add request in here:
https://etherpad.openstack.org/p/ocata-nova-non-priority-feature-freeze https://etherpad.openstack.org/p/pike-nova-non-priority-feature-freeze
(ideally with core reviewers to sponsor your patch, normally the (ideally with core reviewers to sponsor your patch, normally the
folks who have already viewed those patches) folks who have already viewed those patches)
- make sure you make your request before the end of the feature freeze - make sure you make your request before the end of the feature freeze
@ -376,7 +376,7 @@ For blueprint and spec features, do everything for blueprint-only
features and also: features and also:
- If it's a project or subteam priority, add it to: - If it's a project or subteam priority, add it to:
https://etherpad.openstack.org/p/ocata-nova-priorities-tracking https://etherpad.openstack.org/p/pike-nova-priorities-tracking
- Ensure your spec is approved for the current release cycle. - Ensure your spec is approved for the current release cycle.
If your code is a project or subteam priority, the cores interested in If your code is a project or subteam priority, the cores interested in
@ -782,7 +782,7 @@ get, and increase the velocity of getting code merged.
The first part is for subgroups to show they can do a great job of The first part is for subgroups to show they can do a great job of
recommending patches. This is starting in here: recommending patches. This is starting in here:
https://etherpad.openstack.org/p/ocata-nova-priorities-tracking https://etherpad.openstack.org/p/pike-nova-priorities-tracking
Ideally this would be done with gerrit user "tags" rather than an Ideally this would be done with gerrit user "tags" rather than an
etherpad. There are some investigations by sdague in how feasible it etherpad. There are some investigations by sdague in how feasible it