Hi Justin and Dave, Thank you both for the feedback.
Justin, You are correct on all four podling value corrections: - private_list: private@<project>.apache.org (mine was stale). - vote_rule: Must have at least three +1s and more +1s than -1s. - governing_body: IPMC is the PMC of record; the PPMC is delegated. - binding_voters: Depends on the vote (PPMC members on the podling's list; IPMC members on general@). The last two represent a modeling error on my part. I designed governing_body and binding_voters assuming a single governing body per podling, but authority depends on which list the vote takes place on. A single key per project cannot express this, so I will update the design to specify bodies per action before building. Regarding Question 2, I agree and will drop the "move all ten" framing. Most of the release procedure is identical for podlings and TLPs. The podling deltas apply to vote-draft, vote-tally, verify-rc, promote, and announce-draft. For releasecheck, it is already integrated via Magpie (organizations/ASF/skill-sources.md, ref releasecheck-0.5.1), so podlings can install it directly. I will document this recommendation accordingly. For the other four skills, using podling overrides rather than forked copies is the right approach. This allows the Incubator to manage podling-specific procedures in its own repository and on its own release cadence. What I Need Next To move forward and avoid stale configuration files copied across projects, I am asking for body ownership: - Incubator PMC: Will you take ownership of the podling value set (with the corrections above)? - ComDev PMC: Will you take ownership of the TLP value set? If either group declines, I will remove the stage tier from the design. Dave, 1. Release Tools: Justin's RC checker and Magpie's ten release-* skills are separate efforts. The checker's home is a Legal Affairs / ATR discussion. 2. PMC Customization: Magpie uses a "most-specific-wins" resolution hierarchy (project -> stage -> organization -> framework default). PMCs can override any value locally or write procedural overrides. On adoption, agent reviews existing processes and propose any deviations to be saved as a "PMC override." 3. Whimsy Roster Tool: The skill links to a URL and reads rosters via MCP. If the roster tool changes, a body-owned value set allows us to update one repository rather than manually updating every project config. Model Capabilities & Economics Magpie documents capability requirements and token usage here: https://magpie.apache.org/docs/mode-economics/ - No Magpie skill requires a frontier model; mid-tier (~70B) is the recommended default, while small models (~7–13B) handle basic triage. - committer-onboarding requires 8,387 tokens, and a post-vote walkthrough uses 10–30K tokens. The ten release-* skills range from 5,604 to 8,777 tokens each. - Local and self-hosted inference (Ollama, vLLM, llama.cpp) is fully supported. We will soon publish benchmarking data using the three llmao models (tracked in https://github.com/apache/magpie/issues/1260). If adding a per-skill "minimum viable class" column to the docs would be helpful, I can add that as well. Reference Links: - Design doc: https://github.com/apache/magpie/blob/main/docs/designs/2026-09-17-body-owned-config-layers.md - ComDev tracker: https://github.com/apache/comdev/issues/45 Best regards, Jarek -- Drafted with AI assistance (Claude Opus 5) and reviewed before sending. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
