Please note that some commits may be excluded from this release if they’re not relevant, or not modifying the GuestOS image. Additionally, descriptions of some changes might have been slightly modified to fit the release notes format.
To see a full list of commits added since last release, compare the revisions on GitHub.
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.
Please note that some commits may be excluded from this release if they’re not relevant, or not modifying the GuestOS image. Additionally, descriptions of some changes might have been slightly modified to fit the release notes format.
To see a full list of commits added since the last release, compare the revisions on GitHub.
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.
I wanted to make sure that I understood what was happening here, as it’s unusual and really not obvious. I filtered my git client to show only the two relevant branches to cut down on all the noise, and then produced this modified screenshot to illustrate the situation (highlighting the ‘merge base’ commit that’s referred to in the proposal summary, along with the previous release and this proposal’s release).
You can see that the previous release is left out on a limb and is never merged (effectively discarding that commit with respect to this release). The discarded commit isn’t actually a GuestOS commit (what a distraction ).
Just a final comment on the matter - the commit is actually cherry picked back into this release branch (so actually the changes aren’t really discarded after all, they are included in this release… ). Not only that but the commit includes a few subtle additional changes this time around.
The point I’m emphasising is that the IC repo uses git in an unconventional way that makes it very difficult to get a handle on what’s going on. There’s no reason the original commit couldn’t have been merged into the new release branch, and an additional commit made for the updated changes. This approach would have:
Avoided the distracting and inaccurate comment about changes being removed
Avoided unnecessary release branch divergence
Saved me (and perhaps others) unnecessary effort to understand what’s going on
I’d expect these to be goals for any Web3 project that’s serious about governance decentralisation. Is there any chance of introducing best practice policy to improve matters here @basvandijk?
Hey @pakhomov-dfinity1, I found this commit particularly interesting Are you able to share some further information about why there can be a divergence when a checkpoint is loaded? Presumably this can be an issue when nodes are newly added to a subnet? Other than raising a critical error, would you be able to elaborate on what the consequences of this are? Presumably a node in this situation would be considered degraded (or down)? Thanks in advance
Any divergence in this context means a bug in the replica code, which we want to catch as soon as possible, which is the goal of this PR
Some fields are benign and don’t matter, others could lead to a more usual definition of divergence: divergence of Manifest. In this case the node crashes, restarts and does state sync. If more than 1/3 of nodes diverge, the subnet stalls.
Please note that some commits may be excluded from this release if they’re not relevant, or not modifying the GuestOS image. Additionally, descriptions of some changes might have been slightly modified to fit the release notes format.
To see a full list of commits added since last release, compare the revisions on GitHub.
Other changes:
7d81b536b Interface,Networking: fix: revert the old error string when outcall response is bigger than the limit
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.
Please note that some commits may be excluded from this release if they’re not relevant, or not modifying the GuestOS image. Additionally, descriptions of some changes might have been slightly modified to fit the release notes format.
To see a full list of commits added since last release, compare the revisions on GitHub.
Other changes:
7e136416c Interface,Networking: fix: revert the old error string when outcall response is bigger than the limit
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.
).
). Not only that but the commit includes a few subtle additional changes this time around.
Are you able to share some further information about why there can be a divergence when a checkpoint is loaded? Presumably this can be an issue when nodes are newly added to a subnet? Other than raising a critical error, would you be able to elaborate on what the consequences of this are? Presumably a node in this situation would be considered degraded (or down)? Thanks in advance 
