Conversation
PiotrKorkus
requested review from
PandaeDo,
aschemmel-tech,
masc2023 and
pahmann
as code owners
|
|
|
The created documentation from the pull request is available at: docu-html |
masc2023
left a comment
masc2023
left a comment
There was a problem hiding this comment.
Fine for me, beside the location of the content, see comment
PandaeDo
left a comment
PandaeDo
left a comment
There was a problem hiding this comment.
I really appreciate this description. And I suggest to merge it to have an initial version. But afterwards it shall be improved that somebody from outside can understand it better.
PiotrKorkus
force-pushed
the
piotrkorkus_release_process
branch
from
a5bf59e to
235e08a
Compare
LittleHuba
left a comment
LittleHuba
left a comment
There was a problem hiding this comment.
Will block this for the moment until I have reviewed it. Based on the description my approval is mandatory, so I enforce it with this block.
|
We will update the PR and therefore integrate it in the release management plan and also update the release process description. But please feel free to add your comments on this PR. I'll integrate them in the update as possible. |
PandaeDo
force-pushed
the
piotrkorkus_release_process
branch
from
5ca94fd to
47d2438
Compare
| #. Tooling release | ||
| #. Code freeze | ||
|
|
||
| **Integration phase (2 weeks) :** |
There was a problem hiding this comment.
Suggestion: Rename "Integration phase" to "Release phase"
Since we have continuous integration in place, calling this the "Integration phase" seems a bit inconsistent. Would it make more sense to rename it to "Release phase"? This would better reflect what's actually happening at this stage
There was a problem hiding this comment.
Do we have continuous integration? Like, is that still a goal? Is there a way to make it work while relying on explicit releases for score releases? Does it even make sense? e.g. when continuous is green, it does not mean that some module will actually release that version.
Sorry if this is destructive. But if we cannot re-agree on the goals, then we don't need to bother with the technical details.
There was a problem hiding this comment.
I think it's still a goal to have CI. I think CI makes sense, even if modules will not release from what you have on main, it does not matter, You still have continous feedback what happens on main of all modules, incompatilbities etc. And at the end, in most cases release will be around the main when branchof point for it happens.
OFC reality may later validate us being wrong above, then we adapt ;)
|
|
||
| Module Maintainers 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. |
There was a problem hiding this comment.
I'm wondering about the workflow here – if module maintainers have already specified the hash/version to use, what's the benefit of having them also create a PR? It seems like this could be streamlined by having the integration team handle PR creation, which would reduce review burden and help us move faster. Thoughts?
There was a problem hiding this comment.
Where maintainers specified a version? With a PR we have clear message which version shall be used + approvals system out of the box.
How otherwise would you collect information about versions from each of the modules?
| * ``bazel_common/score_modules_tooling.MODULE.bazel`` | ||
| * ``bazel_common/score_qnx_toolchains.MODULE.bazel`` | ||
| * ``bazel_common/score_rust_toolchains.MODULE.bazel`` | ||
|
|
There was a problem hiding this comment.
What about quality toolings like linters/sanitizers/ req. traceability tooling
So repos like score_cpp_policies, etc.
There was a problem hiding this comment.
I would refer to all of them as "tools" in general. Linters, traceability etc. are located currently in score_modules_tooling. If there are new tools that need to be added for the release they can be included in one of those files or new one within bazel_common/
There was a problem hiding this comment.
Okay so you want to distinguish toolchains vs tools? Why? What is the benefit of this differentiation?
| -------------------------- | ||
|
|
||
| Module Maintainers 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. |
There was a problem hiding this comment.
Why do we work on PRs / Hashes here? I though we use bzl_mod in all repos. Then all that needs to be done is a check did bzl_mod version change in last 8 weeks. If not that module did not have an updates to contribute in the next release.
There was a problem hiding this comment.
Reference_integration goal is to provide continuous integration so every push to main branch of any module triggers an update in ref_int. If there are no issues the hash is bumped.
This way on main branch of ref_int we always have newest hash of the module that simply works here.
For the releases we want to switch to certain version from bazel registry. It doesnt have to be newest version. It is up to module owners to decide which version will be integrated for the score release. Thats why we need a PR with that information directly from the module owner.
There was a problem hiding this comment.
Hm okay, but shouldn't the rule rather be for the module owners: Do not push to bazel registry what shall not be integrated in proper releases (or if you to tag it "unsafe" or something alike)" 🤔
There was a problem hiding this comment.
Module owner can do the release whenever they want. They can create 5 releases during Development Phase - all are technically correct but they want to use middle one for release.
Same with bugfix releases, we need to fix something in the old release - which version of the module do we pick?
There was a problem hiding this comment.
Yes but the 'central' release should not impose code freezes on those modules and their individual release strategy.
It should be the other way around. If a module has a release they want (or are 'forced' ) to integrate in the central release they should open a PR that bumps the bzl_mod version in the central release repository (and fixes breaking changes in other modules [either in those directly or via patch]).
This way no extra work induced on modules unless they drive the integration which also aligns their resource planing
There was a problem hiding this comment.
But this point is exactly about that
- modules do releases to bcr how they like,
- When the score release is done, they put/say which release to pick
- if there are breaking API changes, yes then others has to be aligned (whichever way)
- The above shall be known upfront by CI/CD so we dont get to know it only during release of S-CORE but once this happens (this is WIP currently)
|
|
||
| Code freeze | ||
| ----------- | ||
| At the end of development phase, each Module must provide a hash of the commit that represents a *code freeze* |
There was a problem hiding this comment.
each Module must provide a hash
povide who and how?
Also why?
considering the Module Maintainers prepare a Pull Request?
There was a problem hiding this comment.
Check line 240 (who)
| Integration of the Modules | ||
| -------------------------- | ||
|
|
||
| Module Maintainers prepare a Pull Request to that branch with updates to the ``known_good.json`` file, |
There was a problem hiding this comment.
known_good.json pins commit hashes per module but does not verify inter module dependency. I faced this challenge when trying to integrate datarouter that needed fixing hashed for unrelated modules. E.g.: scrample and persistency. The current process allows discovering issues during the integration phase; the last leg which is too late to coordinate a fix acoss depending module teams.
There was a problem hiding this comment.
@rmaddikery there is ongoing work that during the development phase, ref_int will have CI of latest modules build automatically and deliver feedback so all divergence and breaking changes are catched daily.
|
" General Release Planning and Execution The reference to the milestones is not valid any more and shall be replaced with https://github.com/eclipse-score/score/milestones |
|
A Workflow Diagram should be added to visualize the steps and timely dependency |
| Release notes | ||
| ------------- | ||
|
|
||
| Project Leads create a branch ``release/version`` with new release notes in ``score_platform`` repository following template: :need:`doc__platform_release_note`. |
There was a problem hiding this comment.
Cant we finally move the release notes to ref int? 😆
| ------------- | ||
|
|
||
| Project Leads create a branch ``release/version`` with new release notes in ``score_platform`` repository following template: :need:`doc__platform_release_note`. | ||
| Module Maintainers create a Pull Request to that branch with updates to the release notes, |
There was a problem hiding this comment.
Personally I hate this practice. Why do we deviate here from normal workflows as we have EVERYWHERE. We integrate on main branch, not on some PR branch.
There was a problem hiding this comment.
#2671 (comment) I would simply apply the linked comment, move notes into ref_int (this is what we announce over Linkedin and other channels anyway) and then all this is not needed and simpler.
|
|
||
| Performed by: Module Maintainers and Project Leads | ||
|
|
||
| Release candidate |
There was a problem hiding this comment.
Maybe the big question here is whether modules should even create releases. Are they "just" part of S-CORE and we can forgo all this crazy overhead and integration phases. Or are they releaseable on their own and score ist just integrating them. It seems we aim for both, which is fine. But we must understand that we'll neither have full efficient CI nor independent modules.
| A patch might be need to fix issues after the release of the module is allready in bazel registry and there is | ||
| no time for another release. Or if its only minor and it's decided to avoid therefore another release. |
There was a problem hiding this comment.
Explaining non trivial / non build-script patches in regards to safety will be quite impossible?!
pawelrutkaq
left a comment
pawelrutkaq
left a comment
There was a problem hiding this comment.
Keeping request change so no one merge it until we have final statement.
| The patch filename must clearly indicate what it addresses. | ||
| For multiple issues, it is preferred to create multiple patches rather than a single patch addressing all issues. | ||
|
|
||
| A patch might be need to fix issues after the release of the module is allready in bazel registry and there is |
There was a problem hiding this comment.
Is there a process what shall happen to these patch file after release? I suppose in most cases these patches shall be integrated into the module repository and then removed from the reference integration.
| ------------- | ||
|
|
||
| Project Leads create a branch ``release/version`` with new release notes in ``score_platform`` repository following template: :need:`doc__platform_release_note`. | ||
| Module Maintainers create a Pull Request to that branch with updates to the release notes, |
There was a problem hiding this comment.
we should link the definition of "module maintainers"
ramceb
left a comment
ramceb
left a comment
There was a problem hiding this comment.
I am not so happy with the overall approach. We should rather aim for a decentral approach e.g. similar as it is described in https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md.
So we should rather work on score contribution guidelines for bazel modules based on anonymous module tests instead of a detailed process description.
We discussed this already with @antonkri.
@ramceb @antonkri shall we dicuss this in TL today to not postpone ? At least for me this looks like as a step before (or part of) what is described really here. |
LittleHuba
dismissed
their stale review
Dismissing my review since the aligned review was published by @ramceb
|
Hi, we discussed the topic in the logging meeting see https://github.com/orgs/eclipse-score/discussions/2685#discussion-9667910. In addition to that we also agreed that the overall goal is to have a common platform. That means it must be consistent. |
15 participants
Has to be signed off by all CFT leads: