docs: release process documentation#168
docs: release process documentation#168PiotrKorkus wants to merge 4 commits intoeclipse-score:mainfrom
Conversation
|
The created documentation from the pull request is available at: docu-html |
There was a problem hiding this comment.
How is that aligned with https://eclipse-score.github.io/score/main/platform_management_plan/release_management.html, @aschemmel-tech for your info
There was a problem hiding this comment.
Linked docs do not tell anything about the process community needs to follow step by step to create S-CORE release. This is a technical guide we will use internally within reference integration team to align.
Then, it will be presented during Monday's tech alignment and once approved can be included into process_description.
There was a problem hiding this comment.
Integrating this in the release mgt process would be great once agreed.
There was a problem hiding this comment.
The link goes not to the process_description, it goes to the PMP of score, so you could already have this document integrated there from the begin. If you integrate it later fine, but just describe it here, would not be binding in my opinion.
Workflows for Release management in General are here, that is process_description
https://eclipse-score.github.io/process_description/main/process_areas/release_management/release_workflow.html
docs/how_to_release.rst
Outdated
| Once all Modules are merged with their *code freeze*, Module Codeowners create a tag on that exact hash following the S-CORE release process, | ||
| provide release notes to the ``score_platform`` team, and ensure that the new release is present in S-CORE's ``bazel_registry``. |
There was a problem hiding this comment.
PR feedback is not mentioned here at all. Modules will create tags without manual integration attempt into bazel registry.
There was a problem hiding this comment.
What kind of feedback we expect? Once the code-freeze is integrated successfully its just a simple swap hash -> version.
Internal release and push to bazel registry should happen without any unexpected issues at this point.
docs/how_to_release.rst
Outdated
| If there are any issues, Module Codeowners can either push fixes to their **dedicated release** branch and update the hash in the PR accordingly, | ||
| or provide patches (see :ref:`ref_int_patching-label`). |
There was a problem hiding this comment.
depending on state etc, they can also push fixes on their main branch and retry the entire process
There was a problem hiding this comment.
what will this base off of? The last release? Then PRs will break due to incompatibilities?
There was a problem hiding this comment.
main branch is not the best choice in this situation as there might be some changes in the meantime which are not intended to be part of the release. This would break the whole idea of the code-freeze.
The base of the release branch is the code-freeze hash. Issues are either fixed on a release branch from code-freeze hash or patched in reference_integration repo.
docs/how_to_release.rst
Outdated
| ========================== ================================== | ||
| Reference Integration Team Prepare integration process | ||
| Module Codeowners Prepare Module's release candidate | ||
| Project Manager Approves S-CORE release |
There was a problem hiding this comment.
Who ist the project manager?
There was a problem hiding this comment.
|
|
||
| .. _ref_int_patching-label: | ||
|
|
||
| Patching Module |
There was a problem hiding this comment.
Patching modules should not be needed or only should be in rare cases. Patches should be applied in the module repo itself.
There was a problem hiding this comment.
Yes, but it's still left open as fallback. Patches then shall be integrated for next release in modules.
There was a problem hiding this comment.
Exacly, preferred way is to patch before release directly in repos but as a fallback we need to have a definition how to handle that.
docs/how_to_release.rst
Outdated
| The integration phase begins with the creation of a **release branch** in the ``reference_integration`` repository. | ||
| Module Codeowners prepare a Pull Request to that branch with updates to the ``known_good.json`` file, pointing to the hash of their *code freeze*. | ||
| They may update other JSON fields for their Module as needed. Automated workflows will build and test to provide clear feedback directly in the PR. | ||
| If there are any issues, Module Codeowners can either push fixes to their **dedicated release** branch and update the hash in the PR accordingly, |
There was a problem hiding this comment.
I would suggest to seperate the modules into two categories.
- a module provides a hash and has to update the hash via a PR in ref_int
- a module provides a branch and from that we will auto update the known_good. This would also require the module to implement the ref_int reusable workflow for PRs
Maybe we also enforce the present of a commit hash in a known_good in order to be able to release. Since S-CORE should be seen as a whole stack a module can only release if they are working together with some set of the other modules.
There was a problem hiding this comment.
releases -> No auto updates, no branches, no hashes at the end. Only versions. hashes on the release branch only until not everything ready and signoff phase executed.
docs/how_to_release.rst
Outdated
| **Development phase (4 weeks) :** | ||
|
|
||
| #. Common release requirements definition | ||
| #. Features' implemntations and improvements |
|
|
||
| During the development phase, the community works on new features and improvements to the Modules. | ||
| Changes are reviewed by Commiters and Module Codeowners. | ||
|
|
There was a problem hiding this comment.
It appears that continuous integration is only occurring at the code freeze/release branch stage. While I recognize this may reflect our current workflow, I wanted to confirm whether this is the approach we want to maintain?
There was a problem hiding this comment.
No, CI will run daily and in will notify modules about issues.
docs/how_to_release.rst
Outdated
| ----------------------- | ||
|
|
||
| Module Codeowners may decide that their Module will not be released with a new version for the S-CORE Product Increment. | ||
| However, they must still ensure that the Module remains compatible with the S-CORE release and does not fail any workflows. |
There was a problem hiding this comment.
Make it explicit that we can reuse previous release but it has to be adapted to current state. not that clear.
docs/how_to_release.rst
Outdated
| There is an additional ``.rst`` file listing every Module and GitHub ID of the Codeowner responsible. | ||
| .. note:: | ||
|
|
||
| Performed by: Reference Integration Team and Module Codeowners |
There was a problem hiding this comment.
some sphinx issue wrongly rendered
| S-CORE tools, toolchains and other dependencies are released at the end of the development phase the latest. | ||
| During the integration phase, no changes other than necessary bug fixes are allowed to give time to the Modules to rebase | ||
| their dependencies and prepare their *code freeze*. | ||
|
|
There was a problem hiding this comment.
maybe refer to certain section of know_good.json so its clear.
There was a problem hiding this comment.
I listed MODULE files instead, known_good doesn't have e.g. toolchains. Maybe we should also add it later when we will covert into config.json
docs/how_to_release.rst
Outdated
|
|
||
| Release interval between S-CORE Product Increments can be divided into two phases: | ||
|
|
||
| **Development phase (4 weeks) :** |
There was a problem hiding this comment.
lets keep 6 weeks as i think this looks like a decision soon after 0.6 release
docs/how_to_release.rst
Outdated
| ----------- | ||
| At the end of development phase, each Module must provide a hash of the commit that represents a *code freeze* | ||
| and serves as a candidate for integration. The hash can be from the **main** or **dedicated release** branch. | ||
|
|
There was a problem hiding this comment.
shall we write that automtatic CI shall ensure that out of box, but module code owner may still change it. Also for modules that
There was a problem hiding this comment.
Modules that what?
Im not sure if I follow correctly, lets sync offline
docs/how_to_release.rst
Outdated
| The Reference Integration Team prepares a final Pull Request and replaces all hashes with the dedicated release versions. | ||
|
|
||
| This pull request has additional workflow checking that every Codeowner has approved the PR signing off their Module's release candidate. | ||
| There is an additional ``.rst`` file listing every Module and GitHub ID of the Codeowner responsible. |
There was a problem hiding this comment.
module owner. Maybe we shall change globally in this document module codeowner -> module maintainer to not confuse with github codeowners
There was a problem hiding this comment.
Probably we are lacking this definition in SCORE https://eclipse-score.github.io/process_description//main/roles/index.html#project-roles-list
But we are talking probably about subset of CODEOWNERs in given module, that should be direct point of contact. I renamed as suggested and lets create this list during config.json conversion.
qor-lb
left a comment
qor-lb
left a comment
There was a problem hiding this comment.
LGTM. Thank you very much for the preparation!
docs/how_to_release.rst
Outdated
| At the beginning, the overall scope and general requirements for the Modules are discussed and | ||
| agreed upon within the S-CORE community, providing clear goals for what must be achieved. | ||
| The scope should define requirements such as: | ||
|
|
||
| * Tooling versions | ||
| * Used toolchains | ||
| * Supported platforms | ||
|
|
||
| rather than specific features' implementation scopes. | ||
|
|
||
| .. note:: | ||
|
|
||
| Performed by: Project Manager and S-CORE community |
There was a problem hiding this comment.
would it make sense to also pickup the definition of target releases based on the process prepared in the OS module: https://eclipse-score.github.io/score/main/modules/os/operating_systems/docs/index.html ?
e.g. the release team will only maintain functional/certifiable level OSs (community OSs should/can be prepared by the OS maintainer during the release phase).
same as feature development, I would only consider changes until the code freeze
docs/how_to_release.rst
Outdated
|
|
||
| Release interval between S-CORE Product Increments can be divided into two phases: | ||
|
|
||
| **Development phase (4 weeks) :** |
docs/how_to_release.rst
Outdated
| **Development phase (4 weeks) :** | ||
|
|
||
| #. Common release requirements definition | ||
| #. Features' implemntations and improvements |
| S-CORE tools, toolchains and other dependencies are released at the end of the development phase the latest. | ||
| During the integration phase, no changes other than necessary bug fixes are allowed to give time to the Modules to rebase | ||
| their dependencies and prepare their *code freeze*. | ||
|
|
There was a problem hiding this comment.
I listed MODULE files instead, known_good doesn't have e.g. toolchains. Maybe we should also add it later when we will covert into config.json
docs/how_to_release.rst
Outdated
| ----------- | ||
| At the end of development phase, each Module must provide a hash of the commit that represents a *code freeze* | ||
| and serves as a candidate for integration. The hash can be from the **main** or **dedicated release** branch. | ||
|
|
There was a problem hiding this comment.
Modules that what?
Im not sure if I follow correctly, lets sync offline
docs/how_to_release.rst
Outdated
| The Reference Integration Team prepares a final Pull Request and replaces all hashes with the dedicated release versions. | ||
|
|
||
| This pull request has additional workflow checking that every Codeowner has approved the PR signing off their Module's release candidate. | ||
| There is an additional ``.rst`` file listing every Module and GitHub ID of the Codeowner responsible. |
There was a problem hiding this comment.
Probably we are lacking this definition in SCORE https://eclipse-score.github.io/process_description//main/roles/index.html#project-roles-list
But we are talking probably about subset of CODEOWNERs in given module, that should be direct point of contact. I renamed as suggested and lets create this list during config.json conversion.
docs/how_to_release.rst
Outdated
| There is an additional ``.rst`` file listing every Module and GitHub ID of the Codeowner responsible. | ||
| .. note:: | ||
|
|
||
| Performed by: Reference Integration Team and Module Codeowners |
docs/how_to_release.rst
Outdated
| ----------------------- | ||
|
|
||
| Module Codeowners may decide that their Module will not be released with a new version for the S-CORE Product Increment. | ||
| However, they must still ensure that the Module remains compatible with the S-CORE release and does not fail any workflows. |
|
|
||
| .. _ref_int_patching-label: | ||
|
|
||
| Patching Module |
There was a problem hiding this comment.
Exacly, preferred way is to patch before release directly in repos but as a fallback we need to have a definition how to handle that.
docs/how_to_release.rst
Outdated
| At the beginning, the overall scope and general requirements for the Modules are discussed and | ||
| agreed upon within the S-CORE community, providing clear goals for what must be achieved. | ||
| The scope should define requirements such as: | ||
|
|
||
| * Tooling versions | ||
| * Used toolchains | ||
| * Supported platforms | ||
|
|
||
| rather than specific features' implementation scopes. | ||
|
|
||
| .. note:: | ||
|
|
||
| Performed by: Project Manager and S-CORE community |
There was a problem hiding this comment.
Updated as needed to reference OS page that was added in newer commit
apply suggestion Co-authored-by: Alexander Lanin <alex@lanin.de> Signed-off-by: Piotr Korkus <piotr.korkus.ext@qorix.ai>
PiotrKorkus
force-pushed
the
piotrkorkus_release_process
branch
from
959394e to
7bd90b3
Compare
| ========================== ==================================================== | ||
| Reference Integration Team Prepare integration process | ||
| Module Maintainers Prepare Module's release candidate | ||
| Project Lead Guides the release process and leads decision making |
There was a problem hiding this comment.
Please add Quality Manager to do formal checks, as defined here https://eclipse-score.github.io/process_description/main/process_areas/quality_management/quality_workflow.html#wf__vy_ap_pltrelease
There was a problem hiding this comment.
at which step is QM supposed to do formal checks? Final release candidate approval + auto check in sign off file?
There was a problem hiding this comment.
Final release candidate approval + auto check in sign off file?
Yes
| -------------------------------------- | ||
|
|
||
| At the beginning, the overall scope and general requirements for the Modules are discussed and | ||
| agreed upon within the S-CORE community, providing clear goals for what must be achieved. |
There was a problem hiding this comment.
Tools for examples, where it is discussed, where it is documented, propose to update it here as it is delivered as part of the release
https://eclipse-score.github.io/score/main/score_tools/score_tools_evaluation_list.html
|
|
||
| Performed by: Module Maintainers | ||
|
|
||
| Release branch creation |
There was a problem hiding this comment.
in general, can we add a section about communication, where e.g. project lead announce officially start of the activities so the S-CORE community and other are informed?
Further once agreed, a simple table overview about the differente steps and responsible teams, etc. at the begin or end for the release cycle would help later to simplify the communication
| * ``bazel_common/score_gcc_toolchains.MODULE.bazel`` | ||
| * ``bazel_common/score_modules_tooling.MODULE.baze`` | ||
| * ``bazel_common/score_qnx_toolchains.MODULE.bazel`` | ||
| * ``bazel_common/score_rust_toolchains.MODULE.baze`` |
There was a problem hiding this comment.
| * ``bazel_common/score_rust_toolchains.MODULE.baze`` | |
| * ``bazel_common/score_rust_toolchains.MODULE.bazel`` |
| At the end of development phase, each Module must provide a hash of the commit that represents a *code freeze* | ||
| and serves as a candidate for integration. The hash can be from the **main** or **dedicated release** branch. |
There was a problem hiding this comment.
Will this be checked manually, that it truly is one of these two things?
| Release candidate | ||
| ----------------- | ||
|
|
||
| Once all Modules are merged with their *code freeze*, Module Maintainers create a tag on that exact hash following the S-CORE release process, |
There was a problem hiding this comment.
So this means the module makes a release branch of decides a hash from main.
It adds this to the known_good.json and if it's all green and merged THEN it makes a release based on that branch / hash, right?
| ----------------- | ||
|
|
||
| Once all Modules are merged with their *code freeze*, Module Maintainers create a tag on that exact hash following the S-CORE release process, | ||
| provide release notes to the ``score_platform`` repository, and ensure that the new release is present in S-CORE's ``bazel_registry``. |
There was a problem hiding this comment.
The release notes are provided to the platform repository, is this correct?
9 participants
No description provided.