Problem
When adopting Magpie, several .apache-magpie-overrides/ values duplicate information that already lives elsewhere in the adopter repo and can drift out of date. Feedback from an adopter (Apache JMeter): a PMC member flagged that the per-project config forces maintainers to hand-copy data that changes often — "stale context is worse than no context" — and asked that Magpie source it from .asf.yaml rather than making everyone duplicate it.
For an ASF project a lot of the adopter config is already available:
.asf.yaml — repo description, homepage, labels, notifications: (→ dev / commits / PR mailing lists), branch protection.- GitHub repo metadata (
gh repo view) — default branch, description, topics.
- CI check names — these are not in
.asf.yaml; they come from .github/workflows/ (often generated, e.g. a matrix.* script), so a hand-maintained check-name map is the most stale-prone surface of all.
Proposal
In the adopt / config flow, prefer deriving from existing sources over asking the adopter to duplicate:
- Auto-source the stable fields — repo, default branch, mailing lists (from
.asf.yaml notifications:), labels — from .asf.yaml + repo metadata, and only fall back to prompting when a value is absent.
- Don't require a per-check-name CI map. Given CI job names are volatile (and often generated), default the CI-check → doc mapping to a single generic pointer unless the adopter explicitly wants finer buckets (still overridable).
- Optionally, re-derive on
/magpie-setup upgrade and surface drift when a sourced value changed, instead of silently keeping a stale copy.
This keeps the committed override surface minimal and removes the maintenance burden the adopter raised.
Context
Problem
When adopting Magpie, several
.apache-magpie-overrides/values duplicate information that already lives elsewhere in the adopter repo and can drift out of date. Feedback from an adopter (Apache JMeter): a PMC member flagged that the per-project config forces maintainers to hand-copy data that changes often — "stale context is worse than no context" — and asked that Magpie source it from.asf.yamlrather than making everyone duplicate it.For an ASF project a lot of the adopter config is already available:
.asf.yaml— repo description, homepage, labels,notifications:(→ dev / commits / PR mailing lists), branch protection.gh repo view) — default branch, description, topics..asf.yaml; they come from.github/workflows/(often generated, e.g. amatrix.*script), so a hand-maintained check-name map is the most stale-prone surface of all.Proposal
In the adopt / config flow, prefer deriving from existing sources over asking the adopter to duplicate:
.asf.yaml notifications:), labels — from.asf.yaml+ repo metadata, and only fall back to prompting when a value is absent./magpie-setup upgradeand surface drift when a sourced value changed, instead of silently keeping a stale copy.This keeps the committed override surface minimal and removes the maintenance burden the adopter raised.
Context
milamberspace/jmeter#1(JMeter adoption PR) — as an interim, the JMeter CI-check map was collapsed to a single generic pointer locally (stale > no context).