mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-07-30 03:53:18 +00:00
pingqiu
d6a2fb92d6
Per architect single-sign of G5-5 §close (`seaweedfs@c78116fd2`): (a) v3-dev-roadmap.md - §3: G5 line note now mentions G5-5 closed at L3 + G5-5C carry-forward - §4: G5-5 row → CLOSED (link to seaweedfs@c78116fd2); G5-5C row added as next active gate with bound pass criterion - §7: G5-5 close commit appended to recently-closed table (seaweed_block@5c4718f + seaweedfs@c78116fd2, L3 reached, #4 carry) (b) v3-phase-15-g5-5c-mini-plan.md (new) v0.1 kickoff - §1 scope: peer recovery trigger after replica restart; reuse T4d-4 primitives (architect binding); no engine logic change - §1.A: three trigger source options (A master observation, B periodic probe, C transport reconnect) with tradeoffs; sw recommends A; final pick deferred to architect ratification - §2: 6 acceptance criteria, hardware step is exactly G5-5 #4 (verify_restart_catchup → GREEN with no harness changes) - §3: 2 new INVs proposed (REPL-PEER-RECOVERY-TRIGGER-001 + -NO-RETRIGGER-LOOP) + 2 deferred ledger pointers from G5-5 close - §4: G-1 N/A (new build, no V2 PORT) - §5: forward-carries from G5-5 §close all addressed - §6: 5 risks tabled - §7: sign table awaiting architect §1-§6 ratification including trigger source pick Standing by for architect ratification of trigger source binding. No code starts until §1-§6 signed.
sw-block
Private WAL V2 and standalone block-service workspace.
Purpose:
- keep WAL V2 design/prototype work isolated from WAL V1 production code in
weed/storage/blockvol - allow private design notes and experiments to evolve without polluting V1 delivery paths
- keep the future standalone
sw-blockproduct structure clean enough to split into a separate repo later if needed
Suggested layout:
design/: shared V2 design docsprototype/: code prototypes and experiments.private/: private notes, phase development, roadmap, and non-public working material
Repository direction:
- current state:
sw-block/is an isolated workspace insideseaweedfs - likely future state:
sw-blockbecomes a standalone sibling repo/product - design and prototype structure should therefore stay product-oriented and not depend on SeaweedFS-specific paths