Proposal to elect new release rc--2024-06-12_23-01

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 in advance :pray:

2 Likes