Thank you DFINITY for this release. As always I really appreciate the effort and skill that went into it.
However, the way in which this proposal has been presented is inaccurate and misleading, and on that basis I’ll be rejecting this proposal. I invite the community to consider following my vote (see here for some general context) → Do U C What IC? 👀 IC Proposals that mislead... and a 10,000 ICP Giveaway!. I’m planning to upgrade my public neuron to a named neuron soon.
9d0d27eb4 is incorrectly referenced in this proposal. It doesn’t actually form part of this release. In addition it’s been referenced multiple times with commit summaries that are unrelated to that specific commit.
For anyone interested, I believe these are the correct commit hashes that should have been referenced by the proposal summary (instead of 9d0d27eb4):
- f9c4b9999 Networking: use the Shutdown struct instead of explicitly passing the cancellation token for the sender side of the consensus manager
- 1d40efc9f Runtime: Revert “feat: Switch to compiler sandbox for compilation”
- d4517755f Consensus: Rename EcdsaPayload
- ff9d79077 Networking(ingress-watcher): Add metric to track capacity of the channel from execeution
- 687010660 Networking,Consensus: move the PriorityFn under interfaces and rename the PrioriyFnAndFilterProducer to PriorityFnFactory
- 6c9c00c39 Message Routing,IDX: check canister queue upgrade/downgrade compatibility against published version
Even when you account for this, I think there are numerous salient commits that are ignored by this proposal summary:
- eb775492d chore: firewall counter exporter (#343)
- 2a530aa8f chore: CON-1257 Rename
ecdsamodules,EcdsaClient,EcdsaGossipandEcdsaImpl(#367) - 460693f61 perf: CON-1360 Reduce cost of cloning tSchnorr inputs (#344)
- 1413afe92 refactor(crypto): CRP-2536 replace ed25519-consensus with ic-crypto-ed25519 in prod (#347)
- dbaa4375c chore(crypto): CRP-2393 Remove support for masked kappa in threshold ECDSA (#368)
I suspect there are more but I’ve already gone over my intended time allocation, and I’m trying to be strict with myself.
On a side note, thanks DFINITY for taking on board my comments regarding 1-commit branches. I gather from the number of commits that are directly on master (instead of explicitly merged in from 1-commit branches) that a change in procedures has been implemented (or this may just be a coincidence 
).
I wouldn’t be surprised if this is the root cause for the worse than normal proposal summary (due to tooling that has to make some assumptions about the repo structure, for practical reasons). Another reason that I think it would be great to plan to get away from the need for this sort of tooling longer term.