Difference between revisions of "Ironic/Specs Process"
(Created page with "== Ironic Specs Process == Starting with Juno cycle, Ironic has adopted new specification approval process, based on that of [https://wiki.openstack.org/wiki/Blueprints#Nova...") |
(→Ironic Specs Process) |
||
| Line 1: | Line 1: | ||
== Ironic Specs Process == | == Ironic Specs Process == | ||
| − | Starting with Juno cycle, Ironic has adopted new specification approval process, based on that of [https://wiki.openstack.org/wiki/Blueprints#Nova Nova]. As previously, you start with getting your blueprint into [https://blueprints.launchpad.net/ironic/ launchpad] | + | Starting with Juno cycle, Ironic has adopted a new specification approval process, based on that of [https://wiki.openstack.org/wiki/Blueprints#Nova Nova]. As previously, you start with getting your blueprint into [https://blueprints.launchpad.net/ironic/ launchpad]. Then you use the same [https://wiki.openstack.org/wiki/Gerrit_Workflow Gerrit process] as with source code, using special repository [https://github.com/openstack/ironic-specs ironic-specs]. |
| − | 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 for a given release by adding them to the specs/<release> directory and posting it for review to Gerrit. The implementation status of a blueprint for a given release can be found by looking at the blueprint in launchpad. After specification is approved in Gerrit, you have to copy | + | 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 for a given release by adding them to the specs/<release> directory and posting it for review to Gerrit. The implementation status of a blueprint for a given release can be found by looking at the blueprint in launchpad. After specification is approved in Gerrit, you have to copy its text back to launchpad blueprint and start working on the implementation. |
Specifications have to be re-proposed for every release. The review may be quick, but even if something was previously approved, it should be re-reviewed to make sure it still makes sense as written. | Specifications have to be re-proposed for every release. The review may be quick, but even if something was previously approved, it should be re-reviewed to make sure it still makes sense as written. | ||
| + | |||
| + | You are welcome to submit patches associated with a blueprint, 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. | ||
Revision as of 14:28, 18 June 2014
Ironic Specs Process
Starting with Juno cycle, Ironic has adopted a new specification approval process, based on that of Nova. As previously, you start with getting your blueprint into launchpad. Then you use the same Gerrit process as with source code, using special repository ironic-specs.
Specifications must follow the template which can be found at specs/template.rst, which is quite self-documenting. Specifications are proposed for a given release by adding them to the specs/<release> directory and posting it for review to Gerrit. The implementation status of a blueprint for a given release can be found by looking at the blueprint in launchpad. After specification is approved in Gerrit, you have to copy its text back to launchpad blueprint and start working on the implementation.
Specifications have to be re-proposed for every release. The review may be quick, but even if something was previously approved, it should be re-reviewed to make sure it still makes sense as written.
You are welcome to submit patches associated with a blueprint, 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.
