mirror of
https://github.com/got-feedBack/feedBack.git
synced 2026-09-11 07:04:31 +00:00
topkoa
c485f02211
Design change, at the maintainer's direction: the gate now checks out feedpak-spec at HEAD instead of a pinned SHA. .feedpak-spec-ref, its 40-char validation step, and the pin-bump machinery are gone. Rationale: it is vital that the app conforms to the spec — the current spec, not a snapshot. The pin bought determinism at the cost of a maintenance loop (bump PRs, a PAT, weekly latency) and a window where the gate verified against a stale spec. Tracking HEAD makes the dev flow fully self-serve with zero upkeep: gated PR -> FEP -> spec merge -> re-run checks -> green. Nothing to bump. The trade-off is accepted with eyes open, and the docs state it: the normal FEP is additive and can only loosen the gate, so it cannot redden anyone's PR. Only a breaking spec change (rare, deliberate, MAJOR per the spec's compatibility policy) turns PRs red repo-wide — which is the correct org-wide signal that the app is out of conformance. The CI job logs the spec SHA each run verified against, so any red run is reproducible. Failure messages now also say why it matters beyond the one PR (also at the maintainer's direction): non-conformance that lands shows up as red CI on every teammate's PR until it is resolved, and only its author can clear it — the FEP route keeps everyone else unblocked. Tone softened throughout (the exceptions-file header now explains rather than shouts). Signed-off-by: topkoa <topkoa@gmail.com>
51 lines
2.8 KiB
YAML
51 lines
2.8 KiB
YAML
# CLOSED grandfather list — manifest keys core reads or writes that predate the
|
|
# spec-conformance gate and that the feedpak spec does not define.
|
|
#
|
|
# Please don't add entries here — CI will flag any PR that grows this list, so
|
|
# it can only shrink over time. That's by design, not distrust: the moment the
|
|
# app touches a key the spec doesn't define, every teammate's PR starts failing
|
|
# the conformance gate too, and whoever added the key is the only person who
|
|
# can fix it. The FEP process below avoids putting anyone in that spot. The
|
|
# feedpak spec's own governance is explicit:
|
|
#
|
|
# "This repository defines the format only. Applications that read or write
|
|
# feedpak ... track this spec as a dependency; they do not drive it.
|
|
# A change is not part of the format until it lands here."
|
|
# — got-feedback/feedpak-spec, GOVERNANCE.md
|
|
#
|
|
# So a new manifest key goes through the feedpak Enhancement Proposal (FEP)
|
|
# process — see feedpak-spec/CONTRIBUTING.md:
|
|
#
|
|
# 1. Open a FEP issue on got-feedback/feedpak-spec describing the problem, the
|
|
# on-disk shape, backward compatibility, and the version bump implied.
|
|
# 2. Land one PR there updating the normative spec, the JSON Schemas, an
|
|
# example that exercises it, and the changelog — together.
|
|
# 3. Back here, re-run this PR's checks. The gate verifies against the spec's
|
|
# HEAD, so once your key is in the spec, the gate goes green.
|
|
#
|
|
# That's the supported route — and usually a quick one for additive keys. If
|
|
# your PR is blocked by this gate, a FEP will get you unblocked properly; an
|
|
# entry here won't (CI rejects it).
|
|
#
|
|
# Entries below exist ONLY because they predate the gate. Each is debt with a
|
|
# tracking issue, and each disappears when its issue is fixed. The gate also
|
|
# fails if an entry goes stale — the spec caught up, or core no longer reads or
|
|
# writes the key — so this file cannot quietly become a place drift hides.
|
|
|
|
exceptions:
|
|
- key: original_audio
|
|
issue: https://github.com/got-feedback/feedback/issues/933
|
|
reason: >-
|
|
Added by #583 (the full mix played while every stem fader sits at unity,
|
|
since demucs recombination is lossy). Core, lib/enrichment.py, and the
|
|
stems plugin all depend on it, but it never went through a FEP and the
|
|
spec does not define it — the drift this gate exists to prevent.
|
|
|
|
The resolution is REMOVAL, not a FEP: the spec already carries the mixdown
|
|
as a stem ({id: full, file: stems/full.ogg}), so this key added a second,
|
|
redundant location for audio to a format that already had one. See #933.
|
|
|
|
Grandfathered so the gate can land green and start blocking the *next*
|
|
instance immediately, rather than blocking on #933. This entry goes away
|
|
when core no longer reads or writes the key.
|