I think its a bit of in-between to be honest. And I would say it is used **more** in incubator because you often need to "straighten" things out and it has educational purpose. I think huge part of what incubator does is to "teach people what it means", where comdev is more of a - how we keep growing and how we keep things "running" once established. I think also the criteria should be: "Who will more likely keep it updated?" - and in this sense, likely incubator - seeing "more diverse" cases and potentially strange licencing issue that we have not solved yet is likely better.
J. On Fri, Sep 18, 2026 at 7:07 PM Dave Fisher <[email protected]> wrote: > 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] > >
