Difference between revisions of "Ironic/Specs Process"
(→Ironic Specs Process) |
(→Ironic Specs Process) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Ironic Specs Process == | == Ironic Specs Process == | ||
| − | + | Ironic specifications are part of the [http://docs.openstack.org/developer/ironic/dev/code-contribution-guide.html#adding-new-features RFE (Requests for Feature Enhancements) process]. | |
| − | + | Starting with the Juno development cycle, Ironic adopted a new specification approval process, based on that of [https://wiki.openstack.org/wiki/Blueprints#Nova Nova]. As previously, blueprints were added into [https://blueprints.launchpad.net/ironic/ launchpad]. The same [https://wiki.openstack.org/wiki/Gerrit_Workflow Gerrit process] as with source code, using the repository [https://github.com/openstack/ironic-specs ironic-specs], is used to add the specification. | |
| − | + | Specifications must follow the template which can be found at [https://github.com/openstack/ironic-specs/blob/master/specs/template.rst specs/template.rst], which is quite self-documenting. Specifications are proposed by adding them to the specs/approved directory and posting it for review to Gerrit. For more information, see the [https://github.com/openstack/ironic-specs/blob/master/README.rst README]. | |
| − | + | Starting with the Kilo cycle, the specification process is slightly different [1]. This new process provides a way to fast-track your idea, but you don't have to follow that process if you don't want to get an initial, high-level review. You can choose to propose a detailed specification instead. | |
| − | You are welcome to submit patches associated with | + | Starting with the Mitaka cycle, blueprints are no longer used. Instead, RFEs are tracked via [https://bugs.launchpad.net/ironic/+filebug bugs]. See [http://docs.openstack.org/developer/ironic/dev/code-contribution-guide.html#adding-new-features Adding new features] for details. |
| + | |||
| + | All approved specifications are available at http://specs.openstack.org/openstack/ironic-specs/. | ||
| + | |||
| + | If a specification has been approved but not completed within one or more releases since the approval, it may be re-reviewed to make sure it still makes sense as written. | ||
| + | |||
| + | You are welcome to submit patches associated with an RFE, but they will have a -2 ("do not merge") until the specification has been approved. This is to ensure that the patches don't get accidentally merged beforehand. You will still be able to get reviewer feedback and push new patch sets, even with a -2. | ||
The [https://review.openstack.org/#/admin/groups/352,members list of core reviewers] for the specifications is small but mighty. (This is not necessarily the same list of core reviewers for code patches.) | The [https://review.openstack.org/#/admin/groups/352,members list of core reviewers] for the specifications is small but mighty. (This is not necessarily the same list of core reviewers for code patches.) | ||
| Line 16: | Line 22: | ||
For approved but not-completed specs: | For approved but not-completed specs: | ||
| − | |||
* cosmetic cleanup, fixing errors, and changing the definition of a feature can be done to the spec | * cosmetic cleanup, fixing errors, and changing the definition of a feature can be done to the spec | ||
Latest revision as of 19:26, 2 March 2016
Ironic Specs Process
Ironic specifications are part of the RFE (Requests for Feature Enhancements) process.
Starting with the Juno development cycle, Ironic adopted a new specification approval process, based on that of Nova. As previously, blueprints were added into launchpad. The same Gerrit process as with source code, using the repository ironic-specs, is used to add the specification.
Specifications must follow the template which can be found at specs/template.rst, which is quite self-documenting. Specifications are proposed by adding them to the specs/approved directory and posting it for review to Gerrit. For more information, see the README.
Starting with the Kilo cycle, the specification process is slightly different [1]. This new process provides a way to fast-track your idea, but you don't have to follow that process if you don't want to get an initial, high-level review. You can choose to propose a detailed specification instead.
Starting with the Mitaka cycle, blueprints are no longer used. Instead, RFEs are tracked via bugs. See Adding new features for details.
All approved specifications are available at http://specs.openstack.org/openstack/ironic-specs/.
If a specification has been approved but not completed within one or more releases since the approval, it may be re-reviewed to make sure it still makes sense as written.
You are welcome to submit patches associated with an RFE, but they will have a -2 ("do not merge") until the specification has been approved. This is to ensure that the patches don't get accidentally merged beforehand. You will still be able to get reviewer feedback and push new patch sets, even with a -2.
The list of core reviewers for the specifications is small but mighty. (This is not necessarily the same list of core reviewers for code patches.)
Changes to existing specs
For approved but not-completed specs:
- cosmetic cleanup, fixing errors, and changing the definition of a feature can be done to the spec
For approved and completed specs:
- changing a previously approved and completed spec should only be done for cosmetic cleanup or fixing errors
- changing the definition of the feature should be done in a new spec
References
[1] http://lists.openstack.org/pipermail/openstack-dev/2014-August/041960.html
