Jump to: navigation, search

Difference between revisions of "Ironic/Specs Process"

(Ironic Specs Process)
(Ironic Specs Process)
Line 12: Line 12:
  
 
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.)
 +
 +
=== Changes to existing specs ===
 +
 +
For approved but not-completed specs:
 +
* this pertains to specs in the same release cycle that they were approved
 +
* 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
 
[1] http://lists.openstack.org/pipermail/openstack-dev/2014-August/041960.html

Revision as of 16:04, 24 June 2015

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, 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 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. Once approved, the blueprint should include the URL to the specification.

Starting with the Kilo cycle, the specification process is slightly different [1].

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.

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:

  • this pertains to specs in the same release cycle that they were approved
  • 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