[e6ccca2e9] IDX,Crypto(crypto): add a pin_cpu flag to rust_bench and set to True in crypto benches
[b63589213] Runtime,Message Routing: Do not open overlay files twice
Chores:
[245c4878e] Boundary Nodes,Node(ic-boundary): add configuration at deploy
[f15d7613c] Consensus: change the visibility of several structs/enums/functions in /rs/consensus/src/ecdsa
[7512e739e] Consensus: when deleting an artifact from an LMDB pool, use cursor::get(last) instead of cursor::iter::last to get the last element in the database.
[63384bde1] Consensus: Adapt the signatures of some of functions to support multiple keys
[dc4f7ad58] Consensus: allow duplicates of the same block payload in the lmdb pool & remove the associated block payload when we remove a block proposal from the lmdb pool
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.
And this week we also have another special build with the new p2p consensus layer enabled. This feature was deployed last week to a number of subnets and performed very well.
Hey @Luka there were actually 3 Replica Version Management proposals (128086, 128087, and 128088) submitted to the NNS to change the replica. However, your forum post only references proposals 128087 and 128088.
You indicated that proposal 128087 is the new IC release and references the change log since git revision 8d4b6898d878fa3db4028b316b78b469ed29f293. That doesn’t seem to match the details of proposal 128087. However, it does match the details of proposal 128086. It seems like proposal 128087 might be a mistake and that proposal 128086 is the actual proposal for the new IC release.
Also, normally when we elect a new IC replica, we also retire old replicas. That is consistent with proposal 128086, but not proposal 128087.
Would you please explain further in case I am missing something? I’m inclined to recommend to the CodeGov team that we reject proposal 128087 and that we review proposals 128086 and 128088. Please advise if you think that would be an incorrect recommendation.
The proposals 128086 and 128087 are electing the same version. The key differences between them is that 128086 doesn’t have fallback update URL, and 128087 has a copy/paste error which includes text for both its release and the release proposed in 128088. (you can that there are 2 features sections and second one includes the same text as 128086.
Additionally, you’re right that proposal 128087 doesn’t retire replicas. This is suboptimal, but we can place another proposal to retire versions or retire them on the next release. The reason they’re missing from this proposal is that tooling already parses out active proposals and skips retiring versions that were proposed to retire in proposal 128086.
In conclusion - 128086 is not usable because it’s missing fallback URL, 128087 is usable but has an extra description (copy/pasted from next release in 128088 proposal) which doesn’t accurately describe the release, and doesn’t retire old versions which we can mitigated by placing another proposal.
Two possible solutions to resolve the issues we have here are: (1) adopt 128087 and place another proposal to retire old versions, or (2) reject 128087 and place another proposal that fixes all the issues. Proposal 128086 has to be rejected in any case.
Thanks for the explanation @Luka. Unfortunately, it appears the CodeGov neuron has reached consensus on all three proposals already and our vote has been cast.
It appears we made the incorrect choice for proposal 128086 because we voted to adopt. I will summarize the reviews later when they are all complete, but I suspect that none of us realized that the second url is a fallback url. I don’t recall the functional purpose of it being discussed in the past among our team. I do recall thinking it was odd that there are two release package urls and that they are the same url, but never realized the payload actually needs both. I now realize this is something that I should have asked for clarification about previously, especially since it is information in the payload. Fortunately, DFINITY can and will still reject this proposal.
We voted to reject 128087. I would have been uncomfortable adopting 128087 anyway since the summary is not accurate due to the copy/paste error you described (the wrong change log since git revision and the claim that it implements the p2p for consensus). Hence, I’m glad we did reject that one in this case.
At this point, my suggestion is that both 128086 and 128087 should be rejected and a new proposal submitted to correct the issues.
Our vote on proposal 128086 highlights a flaw in how the CodeGov neuron is set up. We’ve known about this issue and have plans to mitigate it programmatically in the future. We are building an app that we will use as our primary tool for submitting reviews, summarizing results, casting votes, paying bounties, and keeping records. We are currently calling this the GaaS App (Governance as a Service), which will be open source for anyone to copy and will also be designed for other organizations to use off the shelf independent of CodeGov. Anyway, the voting mechanism that we plan to implement will account for the issue we experienced here where a small minority of reviewers identify an issue with a proposal that justifies a reject from the CodeGov neuron, but too many other reviewers have already cast their irreversible votes. Since our reviewers are configured as Followees for the CodeGov neuron, we currently cast our vote according to the consensus rules built into every neuron. A better approach would be for us to wait until all reviewers have completed their work and cast a vote after evaluating all information that comes from our reviews. It’s a more complicated voting mechanism to do it programmatically and we don’t have that feature available yet. We could do this manually at this time, but so far have elected to stick to automatic voting. It’s something we should reconsider based on this result.
Reviewers for the CodeGov project have completed our review of these replica updates.
Proposal ID: 128086
Vote: ADOPT
Full report: CodeGov community Replica Version Management Reviews channel on OpenChat SPECIAL NOTE: After the CodeGov neuron voted by consensus of our Followees, we learned that there is an error in the payload of this proposals and it will need to be rejected. Please see this comment from @Luka as well as my explanation for this vote. For anyone who has not voted yet, we recommend that you REJECT proposal 128086.
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, @Gekctek, and @hpeebles. The IC-OS Verification was also performed by @jwiegley and @tiago89. I recommend folks talk 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.
Hey @Luka after reading all the reviews, I can confirm that nobody commented about the lack of a fallback url. Hence, I don’t think anyone realized it is required.
After further discussion among the CodeGov team, we have decided that we will not change our neuron Followee configuration at this time. Instead, we plan for all reviewers to check for correctness of the proposal payload. Also, @tiago89 will soon modify his automated build to add several checks regarding proposal correctness that will flag when there are discrepancies. This should suffice until we get a smart contract built into the GaaS App that will offer a more robust solution.
Since we haven’t had a release last week, and the Friday’s NNS proposal for electing a new IC/Replica version had quality issues, we wanted to submit a new proposal today (Monday), hoping that it would be adopted quickly enough to be able to roll it out by the end of the week. Ideally starting the rollout from Wed, if stars align properly this time.
Hey @sat the CodeGov team has reached consensus on this new proposal already and our neuron has voted to Adopt. Everyone has been able to build the replica successfully and nobody has concerns about the proposal details so far. Here is a link to our results, which are still being posted.
