mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-09-29 03:05:59 +00:00
3 changes for clearer dev roadmap:
1. v3-phase-15-mvp-scope-gates.md — added G9A Placement Controller MVP
per architect direction 2026-04-26. Sits between G9 lifecycle and
G10 snapshot. P0 priority. Source rationale: production block
storage needs V2-like operational ergonomics (operator asks for
intent → system computes placement → master mints assignment) but
V3 authority discipline must be preserved (no heartbeat-as-
authority, no V2 promote/demote). G9A bridges the two:
- flat-topology RF placement (NO rack/AZ awareness in P15)
- durable desired topology generation
- explainable candidate filtering (why selected, why rejected)
- replacement-on-drain/disk-loss
- master mints ONLY from desired topology
Explicit non-scope (defer to G20 / P16): rack-aware, hot rebalance,
automatic load movement, multi-master HA, V2 promote/demote.
Updated P0 table, dependency graph §4.5, closure rule §5 #13.
2. v3-dev-roadmap.md (NEW) — 1-page entry point for "where are we,
what's next." Lists 22 P15 gates with status emoji, current
batch state, naming decoder, source-of-truth pointers, recently
closed batches, prediction for after-G5. QA owns; updates at
every gate-close.
3. v3-phase-development-model.md — added §0 header note clarifying
this is methodology-only, NOT current state. Points to
v3-dev-roadmap.md as current-state entry. Methodology sections
(§1-§6, §8-§14) remain canonical.
Doc layer architecture now:
Methodology: v3-phase-development-model.md (stable)
Roadmap: v3-dev-roadmap.md (entry point; updated per gate-close)
Canonical: v3-phase-15-mvp-scope-gates.md (22 gates + closure)
Rationale: v3-product-placement-authority-rationale.md (why G9A)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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