Merge "Add Internal Process Documentation"
This commit is contained in:
commit
aa9fbbde8e
96
doc/source/process/InternalProcessDoc.rst
Normal file
96
doc/source/process/InternalProcessDoc.rst
Normal file
@ -0,0 +1,96 @@
|
|||||||
|
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 <./2021A.rst/>`_ 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.
|
||||||
|
|
||||||
|
1. Make sure tempest/<plugin> sha is correct
|
||||||
|
(test_repositories.tempest/<plugin>.reference)
|
||||||
|
2. Make sure values listed under os_trademark_approval are correct
|
||||||
|
(target_approval, replaces, releases)
|
||||||
|
3. Make sure required_since within lately added tests is equal to an empty
|
||||||
|
string ("") the guideline release and to the target_approval
|
||||||
|
4. Verify all flagged tests should be still flagged - unflag them otherwise
|
||||||
|
5. Verify all advisory tests we still want to be advisory, if not move them
|
||||||
|
accordingly
|
||||||
|
|
||||||
|
1. If you move a test from advisory (probably to required), set
|
||||||
|
required_since to the guideline release and to the target_approval
|
||||||
|
|
||||||
|
6. Check if any of the capabilities are deprecated.
|
||||||
|
7. Repeat the above process for every add-on's next file
|
||||||
|
8. 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.
|
||||||
|
|
||||||
|
1. 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)
|
||||||
|
|
||||||
|
9. Add PTL or project representatives for each project that next file is
|
||||||
|
covering, to review the changes.
|
||||||
|
10. Add Foundation Marketplace representatives to review the proposed
|
||||||
|
guidelines.
|
||||||
|
11. Change status from draft to approved. (after committee review - that will
|
||||||
|
be in separate patch) -> ~ 3 months after PTG
|
||||||
|
12. Copy and rename the newly created .json files to next.json files
|
||||||
|
(<add-on>.next.json) - separate patch
|
||||||
|
|
||||||
|
1. Change status from approved to draft
|
@ -13,3 +13,4 @@ Process Documentation
|
|||||||
TrademarkProgram
|
TrademarkProgram
|
||||||
2021A
|
2021A
|
||||||
procedure
|
procedure
|
||||||
|
InternalProcessDoc
|
||||||
|
Loading…
Reference in New Issue
Block a user