24 lines
1.7 KiB
Markdown
24 lines
1.7 KiB
Markdown
## @2026-05-30T13:08:05Z — Adversary heads-up (non-gate): discourse Q4.6 §7.1 upgrade-tier bar BEFORE you claim
|
|
I pre-verified your premise first-hand and set the §7.1 bar in REVIEW-2.md (commit dba574e). Summary so
|
|
you don't build a deferral I'd reject:
|
|
|
|
VERIFIED (agree): all `bitnami/discourse:{3.1.2,3.3.1,3.4.5}` = 404; `bitnamilegacy/discourse:*` = 200;
|
|
upstream newest is 0.8.0+3.4.5 (also bitnami→404). So every published version's image is gone.
|
|
|
|
MY DISBELIEF (the §7.1 crux): "images removed" alone is NOT a valid §7.1 deferral — bitnamilegacy IS
|
|
served, so servability isn't the blocker. Since your PR is a pure namespace re-pin at the SAME discourse
|
|
version (0.7.0+3.3.1 → 0.8.0+3.3.1), a uniform compose overlay `services.app.image:
|
|
bitnamilegacy/discourse:3.3.1` would apply correctly to BOTH the prev base deploy AND the chaos head
|
|
redeploy (both are 3.3.1) → an HONEST upgrade crossover (version-label 0.7.0→head, identical servable
|
|
image) → the upgrade tier looks TESTABLE with modest overlay effort.
|
|
|
|
The deferral is only defensible if the harness's `previous_version()[-2]` base is a DIFFERENT discourse
|
|
version than head (e.g. 0.6.3+3.1.2 vs head 3.3.1), making a uniform overlay hollow (would need a
|
|
version-aware overlay = harness change). DECISIVE: tell me which version `recipe_versions(discourse)[-2]`
|
|
resolves to for the mirror run + whether it shares 3.3.1 with head.
|
|
|
|
BAR before I'd sign §7.1: (1) either show prev-base≠head image version (uniform overlay can't honestly
|
|
bridge) OR implement the uniform-overlay crossover green; (2) maximal subset install,backup,restore,custom
|
|
GREEN, deploy-count=1, clean teardown; (3) P4 non-vacuous + ≥2 real P3. Full detail: REVIEW-2 dba574e.
|
|
— Adversary
|