c792b2854 Networking(sync-call): Added networking related changes for the sync-call feature.
246d0ce07 Consensus(ecdsa): Add system tests checking several multiple ecdsa keys scenarios & add handle the case when new keys are added to the subnet
Bugfixes:
bc0117af2 Execution,Message Routing,Interface: Store priority_credit and long_execution_mode in the state
5891b4554 Execution,Runtime: Treat the Wasm memory limit 0 as unlimited
e5d15eeaa Execution,Runtime: apply a separate fee for Schnorr signature
d78df25ba Execution,Runtime: count sign_with_schnorr contexts per key
51940c015 Interface: Fix Request and Payload debug formatting
0f9702f9c Networking: add tower-http tracing instrumentation for the axum routers
c78e0fba8 Networking(https_outcalls): Allow headers with same header name
The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
Thanks for the release DFINITY. Itās always useful to have a summary of the relevant changes. Can I ask why commit 48afaff wasnāt included in this summary? Same question for commit 13225f8.
At the time of this comment on the forum there are still 2 days left in the voting period, which means there is still plenty of time for others to review the proposal and vote independently.
We had several very good reviews of the Release Notes on these proposals by @Zane, @cyberowl, @ZackDS, @massimoalbarello, @ilbert, and @Lorimer. The IC-OS Verification was also performed by @tiago89 and @Gekctek. I recommend folks take a look and see the excellent work that was performed on these reviews by the entire CodeGov team. Feel free to comment here or in the thread of each respective proposal in our community on OpenChat if you have any questions or suggestions about these reviews.
@Lorimer thanks for spotting the missing commits and reporting them. The issue has been identified to be a tooling bug that filtered them out inadvertently. The team will fix it moving forward.
The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
Out of interest can I ask how this tool detects changes that are deemend to be relevant? This would be interesting to know.
Also, while thereās some attention on this tool, could I ask if it would be feasible to adjust it such that future proposal summaries reference the merge commits (which tend to have significantly more informative commit messages). I think this could make a big difference to the perceived transparency of the proposal to some members of the community who are interested in peaking at some of the commits (as opposed to developers who are inclined to pull and explore the git graph more fully).
In the past we were using merge commits for changes instead of regular commits but then we faced some edge cases where git wasnāt detecting merge commits properly so some changes were missed. WARNING(technical details): The reason is that git detects merge commits by checking if a commit has more than one parent. And this does not always work. For instance, if someone force-merges/pushes something, without creating a merge commit, or if itās the last commit in the branch.
So Iāve reverted the code to show regular commits. There are two possible paths that I see, going forward:
changing to code to opportunistically search for a merge commit for a particular commit, and use the merge commit if it exists otherwise fall back to the regular commit, or
wait until we migrate to github, when the formatting of the commit messages will change, and by then we may not need to rely on the merge commits at all. The ETA for this is a few months, based on the latest info Iāve heard.
Thanks for doing this @sat. Iām looking forward to seeing this in action.
I had a quick gander at release_notes.py this morning, and was interested to see that the included commits are initially established based on files changed by the commit intersecting with files that are part of any replica packages (established by bazel). But then this decision is overridden if the file(s) are not considered to be owned by the replica teams. It seems like the important thing should be that a file that constitutes a replica dependency has changed (regardless of who is considered to be the owner of that file). Can I ask what sorts of scenarios this is designed to filter out?
I was also interested to see the EXCLUDE_PACKAGES_FILTERS. Does GuestOS actually take a dependency on ā/sns/ā, ā/nns/ā, āckbtcā, and/or āckethā files? Iām interested in why these are explicitly filtered out too
Sns, nns, and other canisters have a separate deployment and separate set of proposals. So there is no benefit from including them into the IC-OS release notes, it would only increase noise.
Sure, but Iām wondering why theyāre resolved as dependencies of GuestOS in the first place. This implies that changes to these components have the potential to change the behaviour of GuestOS. Is that correct?
if not, Iām wondering why bazel considers them to be dependencies
if yes, Iām wondering why theyāre filtered out (given that the proposal is about voting on changes that have been made that will/can affect GuestOS)
Iām not meaning to be difficult, Iām just interested in understanding this better.
Thatās an excellent observation actually. Itās an issue in our build setup, in essence. Guest OS depends on the canister sandbox, which depends on some libraries used by the canisters, and that ruins so many things at the moment. The primary focus of the node team at the moment is sorting this out. So you are pointing out a real problem.
The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
Thanks for this hotfix release DFINITY. The hotfix itself makes sense, but the circumstances and deployment of this hotfix seem curious.
It would appear to be a response to the lhg73 subnet having stalled earlier today (itās since had the replica version elected by this proposal rolled out to it). However, this hotfix is applied on top of a previous replica version that had LSMT disabled. The lhg73 subnet was previously running a replica version that had the LSMT feature enabled. This means two changes have effectively gone in for subnet lhg73 (disabling LSMT, and this particular new hotfix to consistently enforce the reserved cycles limit during canister updates).
Iāve since noticed that the āChangelog since git revisionā commit reference on both hotfix proposals is misleading/incorrect. 130749 references 2dfe3a1 as the commit upon which the hotfix is applied, but itās actually 246d0ce (LSMT enabled). Similarly 130748 references ae3c4f3 as the commit upon which the hotfix is applied, but itās actually e3fca54 (LSMT enabled). Is there something that Iām missing about the choice of āChangelog since git revisionā references in both proposals?
Given that a version of this hotfix isnāt being elected with the LSMT flag switched off, presumably the NNS subnet is ready to have LSMT enabled again (since the change for supporting deterministic time slicing)?
Thanks again for referencing merge commits in the proposal summary. Are you able to offer any commentary on the question above? Iām wondering if this is down to a quirk of the proposal authoring tool, or a one-off issue.
If thereās a need to reference a prior hotfix or feature flag that wasnāt merged into master (and not contained by the current proposal), it seems like a āDiscarded commitsā reference in the proposal summary would be a more correct way of referring to them (or orphaned/abandoned commits, with relation to the proposal).
Then the āChange log sinceā reference is free to refer to the last deployed commit that is actually included in this proposals commit lineage.
Itās an issue in the tooling. The logic for finding the previous commit is rather fundamental at the moment and cannot properly detect previous commit when thereās lots of different versions. Weāll improve this for the next time.
