release-0.3.20 plan: the driver check to 0.3.21, the clock rule, the 10 GB prover tier and the rule put to main
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
parent
b00dc19380
commit
e4cc7fd503
1 changed files with 4 additions and 0 deletions
|
|
@ -397,3 +397,7 @@ Speculative builds on the candidate from the ship worktree, box only, sequential
|
|||
**Main (13:1x BST):** the fallback reading stands (b7cc37e7 by 15:30 BST or 5899f603 stays live and 0.3.20 ships later today on green). Three additions: (1) standing rule, every canary runs a wiped and a kept datadir, the kept-datadir start a named gate in every release, in docs/plans/release-rules.md (rule 4) and the miner-reliability register as its own fault class (asked of the reliability lane); (2) the Windows shape: the pinned Windows node once against a copy of PC 2's datadir (PC 2 only) before PC 1 gets the build (asked of the build-server lane, with the pairs moved to b7cc37e7); (3) the 16:00 report stands, but on green earlier the publish goes out on green with the clock time. The fleet has the rule and runs the kept start on the pod copy, then the wipe canary on c18-1, then the kept read on c18-1 before its restart step.
|
||||
|
||||
**6b94c823's gates on its own binary (the node lane; the lane's "13:56 to 14:08 UK" = about 12:56 to 13:08 BST):** sha b1b7d47b, string 6b94c823. Digest gate: thirteen fields a89be8a7 on both binaries (compat), the sixteen-field object db9a85f9 refused with the mismatch line; the one FAILED check `n3_has_no_peer` is the refused connection's reconnect in flight at the read (harness fix 36d3efdc: the minimum of five reads). Mixed-version gate, ten minutes on the thirteen-field file: digest b0afb2ee on all five, the 5899f603 hub accepted every block the 6b94c823 node mined (146 new, 246 old, 0 rejected), header versions plain 2, counts equal at 536, 695 and 785 through the clean join via the old hub, the join served by the new node, and the new node's restart; the one FAILED check `no_panic_in_any_node_log` is six "Address already in use" panics in the two old nodes' server threads at start (the gates overlapped on ports 29830/29831; now a 20 s gap). So 8097d600's code is clean on both gates by the checks that bear on the binary; the fallback is still not a pin (N13). From here only b7cc37e7 gets gates, on its own binary when its build lands (about 13:48 BST by the clock), lines about 14:05 BST with sha and string.
|
||||
|
||||
**Main (13:2x BST):** the driver check (the Intel lane's b9487dcf on driver-check: the table, the install thread with one elevated prompt, the manifest's drivers object, the row strip; box 219 + 32 + 8, cross green, pre-push 35, UI 32) rides 0.3.21 with the drivers manifest once the NVIDIA and AMD hashes are real; 0.3.20's app tree is closed. Clock: the node lane's "UK" stamps read an hour fast (UTC+2); every estimate is re-read against `TZ=Europe/London date` before it is quoted; the node lane and the fleet told to quote that clock. The 15:30 BST checkpoint is the real clock.
|
||||
|
||||
**The fleet's prover roll, p1-3080 (13:1x BST):** the pair right (28 "pair ok"), 0 paid in its history (2,167 claims), every proof since the pair dies at the compressed step at the memory wall (device_used 9,859 of 9,885 MiB), 29 of 29, miner off the proving step. Per tier: a 10 GB card does not prove on this pair; the failing prover took the 3080's GPU from its miner for 16 hours for nothing. On the shipper's word (fleet config, no key moves): PROVER=0 on p1-3080 with its lock line and the miner's rate before and after; the same reading for standing boxes under 12 GB; one rented 3080 for an hour to measure the lower-memory SP1 threshold. For main: the kit and the app refusing to start proving under 12 GB with the reason shown, until the measured threshold lands. hub-1 is the roll's last box.
|
||||
|
|
|
|||
Loading…
Reference in a new issue