Difference between revisions of "Masakari-specs"

Latest revision as of 18:57, 15 November 2020

This page's contents have been obsoleted by the relevant information in official Masakari docs.

Please look for contributor-related information in there.

In general, it is an error that you arrived here instead of the docs.

Please report/fix places linking to this page to make them link to docs for contributors.

@@ Line 1: / Line 1: @@
-== Masakari Specs ==
+This page's contents have been obsoleted by the relevant information in [https://docs.openstack.org/masakari/latest/ official Masakari docs].
+Please look for contributor-related information in there.
-A spec is needed for any feature that requires a design discussion. All features need a blueprint but not all blueprints require a spec.
+In general, it is an error that you arrived here instead of the docs.
-If a new feature is straightforward enough that it doesn’t need any design discussion, then no spec is required. In order to provide the sort of documentation that would otherwise be provided via a spec, the commit message should include a DocImpact flag and a thorough description of the feature from a user/operator perspective.
+Please report/fix places linking to this page to make them link to docs for contributors.
-Guidelines for when a feature doesn’t need a spec.
-* Is the feature a single self contained change?
-** If the feature touches code all over the place, it probably should have a design discussion.
-** If the feature is big enough that it needs more than one commit, it probably should have a design discussion.
-* Not an API change.
-** API changes always require a design discussion.
-When a blueprint does not require a spec it still needs to be approved before the code which implements the blueprint is merged. Specless blueprints are discussed and potentially approved during the Open Discussion portion of the weekly Masakari IRC meeting.