Hi, > PROPOSED SOLUTION > We propose establishing central value sets and allowing local overrides: > > 1. Centralized Value Sets: > > - Incubator PMC owns podling defaults: > stage: podling > governing_body: PPMC
IPMC? > whimsy_roster_url: https://whimsy.apache.org/roster/ppmc/<project> > <https://whimsy.apache.org/roster/ppmc/%3Cproject%3E> > private_list: private@<project>.incubator.apache.org > <http://incubator.apache.org/> These days it’s usually private@<project>.apache.org > vote_rule: 3 binding PPMC +1s, no binding veto and more +1s than -1s > binding_voters: current PPMC members For the vote on the PPMC list that true, but on teh IPMC list only IPMC votes are binding. > Magpie will resolve these defaults automatically while allowing > project-level overrides. That seems like a good idea. > ===================================================================== > QUESTION 2: Would either group prefer to own the release skills > directly? > > Magpie includes ten ASF-scoped release skills (rc-cut, verify-rc, > vote-draft, vote-tally, promote, announce-draft, keys-sync, > archive-sweep, audit-report, prepare). > > Currently, these skills do not distinguish between podlings and TLPs, > meaning podlings using them are guided through an incomplete process > (missing podling/IPMC nuances). > > Given that skills can now be published independently (e.g., via claude > plugin marketplace add apache/incubator), would the Incubator PMC or > ComDev prefer to own these release skills directly? Magpie can > maintain registry discovery - while still acting as a pass-through for > those who install / adopt Magpie. I don't think the Incubator should take over all ten. Most release steps are the same for podlings and TLPs: cutting the RC, KEYS, the planning issue, the archive sweep and the audit record. The podling differences are in a few steps. A podling release needs a PPMC vote on dev@ and then an IPMC vote on general@, and only IPMC votes are binding to publish the release. The archives need "incubating" in the name and must include a DISCLAIMER. The release goes to dist/release/incubator/<podling>. The announcement needs the incubation disclaimer. That affects vote-draft, vote-tally, verify-rc, promote and announce-draft. For checking an RC, the Incubator already has releasecheck in its marketplace, and Magpie lists the Incubator as a trusted source. Podlings could use it in place of verify-rc. For the other four, I'd suggest the Incubator provide podling overrides, using the agentic override mechanism from Question 1, rather than separate copies of the skills. Kind Regards, Justin
