Correct - for the "parameters" - it's as easy. If we decide that some of the SKILLs should be "managed" by Comdev/ Incubator - this is also more "we want to keep it updated" - this is what happens now with the Incubator SKILL - any updates there can be done without Magpie's involvement - maybe when new version appears we pin to it.
J. On Fri, Sep 18, 2026 at 4:04 PM Rich Bowen <[email protected]> wrote: > 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] > >
