Internal Process Documentation¶
Here we document all internal (within the IWG group) actions needed in order to release a new guideline. This documentation should help to avoid mistakes and to ensure that every guideline is released in a standardized way.
This document is based on OpenStack Interop Working Group Process 2021A although it focuses more on the internal (within the IWG group) actions, such as order of reviews, their content and timing.
Actions done during a cycle¶
This section summarizes actions in a suggested order IWG team should focus on during the cycle.
See if we have any new tests (for projects currently covered by Interop) in tempest which haven’t been added to interop yet, (this script will help here https://review.opendev.org/c/osf/interop/+/799201)
If there are new tests, decide whether they are worth to be included in any (maybe new) capability.
If yes, add them to a capability / create a new one.
when creating a new capability make sure that required_since is empty - it will be set once the capability gets under required (new ones are under advisory)
If not, add them to the exclude list with a brief explanation why so that the test won’t come up in a future release.
See if we have any new deprecated tests in Tempest or if any tests got removed from Tempest recently (only tests related to the projects under Interop coverage concern us). E.g. go through merged patches within the relevant time frame.
If there are any deprecated tests, let’s deprecate the capabilities which contain the deprecated tests (move them from required to deprecated in the relevant next files). Don’t forget to mention a related link in the commit message (f.e. tempest change which deprecated the tests).
If there are any removed tests, verify whether the related capabilities were deprecated already.
If they were, consider moving the capabilities to removed section.
If they were not, deprecate them. They will be removed in the next cycle.
Watch out for any reported issues or skips (f.e. in the upstream CI) of tests which are part of any capability which is currently under advisory. This info will be crucial in the release process when we decide whether to move the advisory capabilities to the required section.
Release process (starting 1 month before PTG)¶
Changes to be done within next.json files are documented in this section.
Make sure tempest/<plugin> sha is correct (test_repositories.tempest/<plugin>.reference)
Make sure values listed under os_trademark_approval are correct (target_approval, replaces, releases)
Make sure required_since within lately added tests is equal to an empty string (“”) the guideline release and to the target_approval
Verify all flagged tests should be still flagged - unflag them otherwise
Verify all advisory tests we still want to be advisory, if not move them accordingly
If you move a test from advisory (probably to required), set required_since to the guideline release and to the target_approval
Check if any of the capabilities are deprecated.
Repeat the above process for every add-on’s next file
Rename next.json to <target_release.json> - in case there are other changes in the next.json file, do this step in a separate patch as the rename appear in gerrit as a new file which makes it harder to see other changes within the file.
Edit required_platform_components.source references in the add-on next files so that they point to the new platform guideline being released (next.json -> <target_release>.json)
Add PTL or project representatives for each project that next file is covering, to review the changes.
Add Foundation Marketplace representatives to review the proposed guidelines.
Change status from draft to approved. (after committee review - that will be in separate patch) -> ~ 3 months after PTG
Copy and rename the newly created .json files to next.json files (<add-on>.next.json) - separate patch
Change status from approved to draft