Not sure I’m following all of the objections, but as I understand this, it’s a pretty simple ask - that we stash a file in our git repo as a source of truth, yes?
I propose we put the file in github.com/apache/comdev under a governance/ directory — something like governance/tlp-governance-defaults.yaml. That gives us a natural place to maintain it, and anyone on the ComDev PMC can update it via PR. Does that work for you? I'll put a starter file there shortly so you have something concrete to point Magpie at. If the shape of the YAML needs to change to fit your schema, just open a PR or an issue and we’ll sort it out. On the release skills question — I agree with Justin that overrides are the right approach. We don't need to own separate copies of skills that are 95% identical. How’s this to start: # organizations/ASF/stages/tlp.md — sourced from apache/comdev stage: tlp pmc_of_record: PMC delegated_body: PMC # same body for TLPs whimsy_roster_url: https://whimsy.apache.org/roster/committee/<project> private_list: private@<project>.apache.org votes: committer: list: private@<project>.apache.org binding_voters: PMC members rule: at least three +1s, and more +1s than -1s release: - list: dev@<project>.apache.org binding_voters: PMC members rule: at least three +1s, and more +1s than -1s publishes: true —Rich > On Sep 18, 2026, at 6:24 AM, Jarek Potiuk <[email protected]> wrote: > > 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
