Proposal to elect new release rc--2024-09-26_01-31

[Lorimer]

@Luka

But I guess this is just a drawback of current implementations. I think it’s better to let the community know about these changes when it’s perfectly possible that a new node will be deployed and used in a subnet with these changes rather than hiding it

This makes sense, but I think there needs to be consistency. If SetupOS changes are to be included in GuestOS proposal change logs, and HostOS is a dependency of SetupOS, then HostOS changes should also always be included in GuestOS proposal change logs (even though HostOS isn’t the deployment target).

This reminds me of a Zoom chat we had a little while ago @sat, where @andrewbattat’s very insightful suggestion came up.

@andrewbattat

My personal vision is to have a weekly “IC-OS” release that would include changes for all IC-OS images, and then after the release is approved by the community, we would do GuestOS/HostOS upgrades based on the latest approved IC-OS release. This is more of DRE’s domain though (@sat)

How close are we away from something like this? As we discussed, it wouldn’t matter if there are no plans to deploy the elected HostOS changes (immediately). It would be more about giving NNS voters frequent and consistent oversight (and a say) in the HostOS changes that are taking place.

[sat]

@Lorimer

How close are we away from something like this? As we discussed, it wouldn’t matter if there are no plans to deploy the elected HostOS changes (immediately). It would be more about giving NNS voters frequent and consistent oversight (and a say) in the HostOS changes that are taking place.

We discussed this in our standups, and we’d like to do it. But we don’t have it as a high-prio item since no one requires this urgently. We’ll get to it soon. But if someone from the community wants to assist and prepare a PR, I’d be very happy to review

We could in principle also consider offering small grants for such contributions, if there would be interest?

[Lorimer]

Thanks @Sat, sounds fair that this is a low priority item.

Thanks for the invitation. I like getting my hands dirty, but they’re currently too occupied with other things. Would be great if anyone else out there wants to pick this up.

In the meantime it sounds like it would make sense to include all GuestOS, SetupOS and HostOS commits in the GuestOS propsal summary change log (even though it’s only strictly GuestOS that will be affected by the proposal).This would mean that in the future when a HostOS proposal is raised (featuring lots of changes that have built up), the only thing that should need to be verified is the build and that all of the HostOS commits have previously been included in GuestOS proposal change logs (and therefore reviewed and accepted by the community already).

I do think we need consistency and clarity with this though. Either these changes should always feature in the GuestOS proposal summary, or they shouldn’t. Otherwise we’re all going to end up duplicating work, and not quite knowing what’s been reviewed previously etc.

@Luka from your comment above it sounds like you’d be happy with this. What do you think?

[aligatorr89]

Hi! What is a rank-0 block maker ?

[aligatorr89]

I mean, what rank-0 means, not what is block maker

[Lorimer]

Hey @aligatorr89, nice to see you here! The rank 0 block maker is the primary block maker. If this fails then other ranked block makers are used (it’s a fallback mechanism, organised by something fancy called a random beacon) →

Internet Computer Consensus | Internet Computer

[aligatorr89]

Thanks for clarifying @Lorimer , I will give it a deeper read. Btw, congrats for WTN bounty reward, I voted for it

[Luka]

Agreed, it might make sense to update HostOS from the same blessed version as GuestOS and then include all the changes in these proposals. We might start adding these changes to GuestOS releases soon but not sure when will be able to use the same version for HostOS upgrades. We might need to re-bless it as workaround until the changes are implemented.