Audit action correction: release no production

Ref: Resolves #89

Author: aschemmel-tech

process/folder_templates/modules/module_name/docs/release/release_note.rst

@@ -46,6 +46,12 @@ Release Note
 | This document provides an overview of the changes, improvements, and bug fixes included in the software module release version vX.Y.Z
 |  as compared to the module's origin release (which is usually the previous release).
 |
+|  Disclaimer
+|  ----------
+|  This release note does not "release for production", as it does not come with a safety argumentation and a performed safety assessment.
+|  The work products compiled in the safety package are created with care according to a process satisfying standards, but the S-CORE project,
+|  being a non-profit and open source organization, can not take over any liability for its content.
+|
 | New Features
 | ------------
 |

process/process_areas/release_management/guidance/release_guideline.rst

@@ -18,7 +18,7 @@ Guideline
 .. gd_guidl:: Release Management Guideline
    :id: gd_guidl__rel_management
    :status: valid
-   :complies: std_req__iso26262__management_64131, std_req__iso26262__management_64132, std_req__iso26262__management_64133, std_req__iso26262__management_64135
+   :complies: std_req__iso26262__management_64131, std_req__iso26262__management_64132, std_req__iso26262__management_64133, std_req__iso26262__management_64134, std_req__iso26262__management_64135
 
 .. _workflow_release:
 
@@ -27,7 +27,7 @@ Software Module Release
 
 1. **Repository Management**:
 
-   * Each software module is contained in its own GitHub repository.
+   * Each software module is contained in its own repository.
    * Ensure that the repository follows the standard naming conventions and structure.
 
 2. **Release Planning**:
@@ -46,13 +46,15 @@ Software Module Release
 
    * Update the version number according to the versioning policy of your module (defined in release management part of the :need:`gd_temp__platform__mgmt_plan`).
    * Prepare release notes documenting the changes, improvements, and bug fixes.
+   * Check if all planned documents and work products are in valid state.
    * Ensure the module's safety package is available and complete.
-   * Tag the release in the GitHub repository.
+   * Tag the release in the repository.
 
 5. **Release Execution**:
 
-   * Create a release in the GitHub repository release branch and attach the release notes. For this consider the `GitHub Howto Release <https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository/>`_
+   * Create a release in the repository release branch and attach the release notes. For this consider the `Howto Release <https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository/>`_
    * Notify the project lead circle about the release for approval.
+   * One of the project leads will give a review approval for the release note in the versioning tool, which is equivalent to his signing the release.
 
 
 Platform Release
@@ -81,13 +83,15 @@ Platform Release
    * Check if modules are released.
    * Update the platform version number according to the versioning policy (defined in release management part of the :need:`gd_temp__platform__mgmt_plan`).
    * Prepare platform release notes summarizing the updates from all integrated software modules.
+   * Check if all planned documents and work products are in valid state.
    * Ensure the relevant safety packages are available and complete.
-   * Tag the platform release in the GitHub repository.
+   * Tag the platform release in the repository.
 
 5. **Release Execution**:
 
-   * Create a release in the GitHub repository release branch and attach the platform release notes. For this consider the `GitHub Howto Release <https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository/>`_
+   * Create a release in the repository release branch and attach the platform release notes. For this consider the `Howto Release <https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository/>`_
    * Notify the project lead circle about the release for approval.
+   * One of the project leads will give a review approval for the release note in the versioning tool, which is equivalent to his signing the release.
    * Publish within Eclipse SDV.
 
 
@@ -96,7 +100,7 @@ Tracking and Communication
 
 1. **Tracking**:
 
-   * Use the github project management tools to track the progress of software module releases and the platform release.
+   * Use the project management tools to track the progress of software module releases and the platform release.
    * Maintain a release calendar to visualize the timelines and milestones.
 
 2. **Communication**:

process/process_areas/release_management/guidance/release_templates.rst

@@ -32,6 +32,12 @@ Templates
    |  This document provides an overview of the changes, improvements, and bug fixes included in the platform release version vX.Y.Z
    |  as compared to the platform origin release (which is usually the previous release).
    |
+   |  Disclaimer
+   |  ----------
+   |  This release note does not "release for production", as it does not come with a safety argumentation and a performed safety assessment.
+   |  The work products compiled in the safety package are created with care according to a process satisfying standards, but the S-CORE project,
+   |  being a non-profit and open source organization, can not take over any liability for its content.
+   |
    |  New Features
    |  ------------
    |  - **Feature 1**: Brief description of the new feature.
@@ -99,10 +105,10 @@ Templates
    | -------------------------------------------------------
    |
    | 1. Link this issue to the correct milestone and assign to the technical lead
-   | 2. Check respective Verification report on the release candidate's github tag
+   | 2. Check respective Verification report on the release candidate's baseline
    | 3. Check bugfixes or justify failed tests
    | 4. Check the safety package completeness (includes "valid" documents and work products status, supported by the safety manager)
    | 5. Create/update the release note (pull request to close this issue)
-   | 6. Document safety manager's "recommendation to release" by asking his GitHub review approval of the release note
-   | 7. Create the "release" in GitHub according to :need:`gd_guidl__rel_management`
+   | 6. Document project manager's consent by asking review approval of the release note
+   | 7. Create the "release" in version management tool according to :need:`gd_guidl__rel_management`
    | 8. Merge PR and close this issue to complete the release