fd6aca6271
Upon review, we found that we do NOT need breaking changes to the schema. In this minor revision, we are adding keys and placing forward references to the new keys from the old ones. At this point, we've removed the tests as per 2015.05 guideline. These will be added back over time. SUMMARY: added: reference added: tests-repositories added: required-since added: tests now have block including idempotent_id and (optional) flagged information change: guidelines to point to required-since change: tests from array to hash change: add hash after test-name keys change: flagged points to new location tests/test-name/flagged change: new version 1.3 To match the reference field, added new schema.1.3.rst file with explanation of the json schema. This file was expanded to include items that were added in 1.2 but not documented. The schema.1.2.rst file was added to preserve the json schema removed from the README.rst file. It was not otherwise changed. Expanded HACKING file to capture flagging mechanics. Co-Authored-By: Rob Hirschfeld <rob@zehicle.com> Co-Authored-By: Chris Hoge <chris@openstack.org> Co-Authored-By: Mark T. Voelker <mvoelker@vmware.com> Change-Id: I61483f988bdb1f4deb18266f611044b24ba65c34
2.9 KiB
2.9 KiB
DefCore Style Commandments
- Step 1: Read the OpenStack Style Commandments http://docs.openstack.org/developer/hacking/
- Step 2: Read on
DefCore Specific Commandments
- [D300] When adding tests to "flagged" lists, generally only the most current Board-approved .json file and the .next.json file should be modified. There is no need to modify older guidelines unless the most current Board-approved guideline doesn't cover the OpenStack release you are concerned with.
- [D301] The "tests" lists in the .json capabilities lists are immutable once approved by the Board. Therefore if you desire to flag a test, in an approved capability list, add a "flagged" block to the test. Do _not remove it from the "tests" section.
- [D302] If a test is found to not meet the DefCore Flagging Criteria defined in this document after the Board has approved a Guideline, the corresponding tests should have a "flagged" block added to the the relevant tests in the "tests" section of the relevant Board-approved Guidelines. - See [D307] for details about format requirements. - See [D308] for conditions on also adding to the .next.json.
- [D303] Tests that are found to inadequately test the underlying Capability, due to bugs or design flaws, should have a "flagged" block added to the section for the test in the "tests" section of the most recent Board-approved Guideline.
- [D304] Before the Board approves the capabilities listed in the .next.json file, a committee member will submit a patch that copies the .next.json file to an appropriately named new file, updates the "status", "replaces", and "id" fields, and updates the "required-since" field within newly required capabilities. The patch should include the matching generated RST version of the JSON file. This patch should be marked as -1 workflow until after approval.
- [D305] DefCore guidelines generally cover the most recent three releases of OpenStack, though the DefCore Committee has the power to determine otherwise. The "releases" section of the .next.json file should generally be updated shortly after the Board approves a release so that contributors can see what releases the proposed Guideline targets.
- [D306] When modifying "comment" and "guidance" sections, refer to definitions and processes found in the "process" directory of the repository rather than duplicating or restating them. This helps us avoid the appearance of having multiple sources of truth.
- [D307] When adding a "flagged" section to a json file, all fields listed in the relevant schema document for the "flagged" section are required.
- [D308] If the reason for adding a "flagged" block is not expected to be resolved before the next Guideline is submitted to tbe Board for approval, then matching entries should also be made in the .next.json Guideline.