chore: remove the last apache-steward references - #1123
Merged
potiuk merged 2 commits intoAug 29, 2026
Conversation
…state The skill read `mergeable` but never `mergeStateStatus`, and GitHub computes `mergeable` lazily — a PR not tested against its base since the last push answers `UNKNOWN`, and keeps answering `UNKNOWN` unless something asks again. In practice every PR in a review session came back `UNKNOWN`, so the headline's "mergeable state" carried no information and conflicts never reached the author. The failure that produces is an approving review on a branch that cannot merge. The author reads the approval as "done" and finds out weeks later, at the merge button, when the reviewer has long moved on. Conflicts stay out of the disposition rules deliberately: a correct PR that merely trails its base should not be gated behind a mechanical rebase. Stating it is enough. Generated-by: Claude Code (Claude Opus 5)
The framework was renamed from apache-steward to Apache Magpie some time ago, but a few references outlived the rename. Drops "Step 0a — Migrate `apache-steward`-era naming" from the upgrade skill and the matching "Migrating a pre-Magpie adopter" section from the install recipes. The two disagreed with each other: the upgrade skill claimed every run performs the migration automatically, while the install recipes said the framework no longer ships an automated migration. Neither statement survives, so the contradiction goes with them. Also updates two stale `setup-steward` skill references in the source-control tool contract to `magpie-setup`, and the framework's name in the AI-authorship-disclosure eval fixture. `apache/airflow-steward` stays in the README acknowledgements: that is project provenance tied to the NOTICE attribution, not a stale label.
potiuk
added a commit
that referenced
this pull request
Aug 29, 2026
…rker (#1130) The default `bot_prefixes` did not list `<!-- apache-magpie: `, the canonical machine marker every framework skill writes on its status-rollup, hand-off, and import comments. Those comments were therefore counted as *human triage activity*, pulling the time-to-triage median toward zero on any tracker the skills touch — and the more the skills are used, the more wrong the metric gets. At the same time the default listed `<!-- airflow-s status rollup v`, a marker specific to one adopter's tracker repo and meaningless to every other project. That is the template-genericity residue the upgrade flow's Step 6d audit exists to catch; #1123 removed the last apache-steward references but this one survived. Swaps the leaked adopter marker for the framework's own. Also corrects the README's merge documentation. It said the `milestones` and `categories` lists are replaced entirely, implying other lists merge. `deep_merge` replaces *every* list — its own docstring says "Lists are REPLACED, not concatenated" — so an overlay adding a single `bot_prefixes` entry silently drops all the defaults. That is precisely the trap that makes this bug hard to notice downstream: an adopter fixes the marker locally and unknowingly discards the rest of the list. Verified: the config still parses under the hand-rolled `_minimal_yaml_load` subset parser with the added comments, `is_bot_body` now classifies a real `<!-- apache-magpie: status-rollup v3 -->` comment as bot while leaving a human triage comment alone, and the tool's 114 tests pass. Generated-by: Claude Code (Claude Opus 5)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
apache-stewardto Apache Magpie some time ago, but a handfulof references outlived the rename.
git grep -i 'apache[-_ ]steward'now returns nothing.apache-steward-era naming fromskills/setup/upgrade.mdand thematching "Migrating a pre-Magpie (
apache-steward) adopter" section fromdocs/setup/install-recipes.md. The two contradicted each other: the upgrade skill claimedevery run performs this migration automatically, while the install recipes said the
framework no longer ships an automated migration. Neither statement survives, so the
contradiction goes with them.
setup-stewardskill references intools/github/source-control.md→magpie-setup.Type of change
docs/,README.md,CONTRIBUTING.md).claude/skills/<name>/) — see note below on eval fixturestools/<system>/*.md)Test plan
prekpasses on every changed file — doctoc (the removed TOC entry), markdownlint, lychee(no anchor left pointing at the deleted sections),
check-placeholders,skill-and-tool-validateuv run pytestpasses intools/skill-evals.claude/skills/magpie-setup/upgrade.mdresolves through the symlink chain to theedited
skills/setup/upgrade.mdwith zerostewardhitsand the one fixture touched is a cosmetic framework-name string, not a decision input
Notes for reviewers
Removing Step 0a means an adopter still on the pre-rename layout gets no automated migration
and no documented manual one. That is deliberate — the rename is long past and the two
descriptions had already drifted apart — but if any adopter is known to still be on
.apache-steward*, this should wait.apache/airflow-stewardis deliberately kept in the README acknowledgements. That isproject provenance tied to the
NOTICEattribution, not a stale label.release flow", "act as a steward of the project") in
docs/vendor-neutrality.md,skills/contributor-nomination/assess.md, andtools/asf-svn/— left alone.