We got the question in discord that we think is important to answer here as well:
When do we anticipate the mesa release after the chain stops? As in, do you expect it to be possible for users to ignore the automation and just switch binaries or you expect a delay of more than
slot_delta?
We suggest the following:
To clarify, this genesis delta is the amount of time between the slot_chain_end (when Berkeley blocks stop being produced completely and when the auto mode daemons generate their config and restart) and the scheduled genesis of Mesa.
Relevant for manual hard fork mode: The post hard fork release (with bundled Mesa config) can only be fully built starting at the slot_chain_end. We want to release the package fast enough that people who opt for the legacy procedure can still install it in time for Mesa genesis.
So, this hard fork genesis delta is also the amount of time available to build the Mesa package, do the testing and validation for that package, release it, and then have it be installed by the end user.
It’s worth emphasizing that for Mesa we must commit to a specific genesis timestamp before the hard fork process starts; the auto hard fork mode needs this parameter to be present in the stop slot release to function correctly. This is in contrast to Berkeley, where the timestamp was set during the hard fork process itself.
Current hard fork packaging pipeline takes ~40 minutes, so having the delta be 2 hours lets us take 1 hour to generate and release the hard fork package, and still give everyone 1 hour to install the post hard fork package.
That would be without further optimization.
We are thinking of doing some optimizations in the pipeline and validation process that would give us even more of a buffer.