Jarek/Justin, Any reason not to host the license checker with comdev instead of the incubator? It’s a common task for every PMC!
Best, Dave > On Sep 18, 2026, at 9:34 AM, Rich Bowen <[email protected]> wrote: > > Does this work for you? > > https://github.com/apache/comdev/tree/main/governance > > >> On Sep 18, 2026, at 11:30 AM, Jarek Potiuk <[email protected]> wrote: >> >> 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] >>> >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
