Repository navigation
release-* family has no ASF incubator/podling handling (IPMC vote, DISCLAIMER, incubator dist paths, -incubating suffix) #1172
Description
I got Claude AI to raise this. I have checked the text for obvious mistakes but apologies if there are things that I missed.
What should happen
The release-* skill family should recognise ASF incubator podlings as a
distinct project stage and adapt its vote, promote, verify, and announce
behaviour accordingly — the way committer-onboarding already forks on
incubating vs graduated.
Why
The framework already models the concept but the release family does not
consume it:
organizations/ASF/organization.md:80declares
project_stage_vocab: [incubating, top-level], resolving the
<project-stage>placeholder documented atAGENTS.md:396.skills/committer-onboarding/SKILL.md:118(Golden rule 5) explicitly forks
the incubating and graduated paths, asks which applies, and adapts every
subsequent instruction.
But grepping incubat|podling|IPMC|general@incubator across all ten
skills/release-*/ directories, docs/release-management/, and
projects/_template/release-management-config.md returns zero matches. A
podling Release Manager running this family today gets guidance that is wrong
in at least six places:
| Gap | Where | Current behaviour |
|---|---|---|
Second IPMC vote on general@incubator.apache.org after the PPMC vote passes |
release-vote-draft, release-vote-tally |
Single-stage vote only. skills/release-vote-tally/SKILL.md:360 hardcodes pass = (binding_plus1 >= 3) AND (binding_plus1 > binding_minus1) against <project-config>/pmc-roster.md — no IPMC roster, no second round |
dist/dev/incubator/<podling>/ and dist/release/incubator/<podling>/ paths |
release-prepare, release-promote, release-archive-sweep |
All assume dist/{dev,release}/<project>/ |
| PPMC vs IPMC write gate | skills/release-promote/SKILL.md:107 (Golden rule 5) |
Checks pmc-roster.md only; a podling RM's promote is gated by the IPMC, not the PPMC |
Mandatory DISCLAIMER / DISCLAIMER-WIP file in the source artefact |
release-verify-rc |
Checks LICENSE / NOTICE / RAT / prohibited binaries — no DISCLAIMER check |
-incubating version-string suffix |
release-verify-rc version-consistency check, release-rc-cut tag |
Not recognised |
| Podling announcement rules | release-announce-draft, projects/_template/release-management-config.md |
The template already says announce@apache.org is "mandatory for ASF TLP releases" — the TLP qualifier is correct, but nothing supplies the podling equivalent |
These are policy requirements from
the Incubator release-management guide
and
the Incubator branding/DISCLAIMER rules,
not stylistic preferences — a podling release that skips the IPMC vote or the
DISCLAIMER file is invalid.
Which layer
Skill (.claude/skills/<name>/)
Boundary conditions
- Stage unset. When no
project_stageis configured, the skills must
behave exactly as they do today (top-level). No silent podling assumptions. - Non-ASF adopters.
release-promotealready has--non-asfto skip PMC
concepts. Podling handling must sit behind the ASF organization adapter and
stay invisible to independent-governance adopters, whose
project_stage_vocabis[]. - Graduation mid-release-train. A project that graduates between RCs will
have-incubatingin an already-published version and not in the next. The
skills should read the stage per invocation rather than caching it across a
train, andrelease-archive-sweepmust still recognise archived
-incubatingversions under the oldincubator/dist path. - Vote-stage ambiguity in
release-vote-tally. With two sequential vote
threads, the skill needs to know which one it is tallying; it should not
merge PPMC and IPMC votes into one count. release_vote_backend = atr. Whether ATR models the two-stage podling
vote at all is unknown — worth confirming before wiring, rather than
assuming themanualshape.
Out of scope
- Graduation itself (board resolution,
committee-info.txt, TLP rename) —
that is governance, not release management. - Changing the existing 3-binding-
+1pass rule for top-level projects. This
proposal adds a second stage for podlings; it does not weaken the baseline. - Podling-specific handling in the
security-*family.
References
organizations/ASF/organization.md:80—project_stage_vocabAGENTS.md:396—<project-stage>placeholder resolution orderskills/committer-onboarding/SKILL.md:118— the incubating/graduated fork to
mirrorskills/release-vote-tally/SKILL.md:352-360— pass-rule evaluationskills/release-promote/SKILL.md:107— PMC membership gate- https://incubator.apache.org/guides/releasemanagement.html
- https://incubator.apache.org/guides/branding.html (DISCLAIMER rules)
Cheapest route is probably a project_stage key in
release-management-config.md plus a committer-onboarding-style golden rule in
release-vote-draft, release-vote-tally, release-promote, and
release-verify-rc.
Activity
potiuk commentedon Sep 8, 2026
Or maybe we should have two separate skills - and routing betwen them depending on the state of the project ? Podling/TLP ?
I thinl this might get us to the discussion started on rai-disucss as well - @justinmclean @rbowen @pjfanning -> what do you think about proceeding with upstreaming back the "incubator" and "comdev" skills back to comdev/incubator, and have two diferent set of those (they might be obviously linked - for example ComDev "release" skill (TLP) could be extended by the "incubator" release skills - with specific differences for incubator - or the other way round.
It's very easy (as of last month) to split it out and have a skill installed from another "distributed marketplace" and overridden locally. with some local changes (and re-exporting that SKILL in your own marketplace).
If you think it is a good idea and we come to agreement who extends whom, I might come up with relevant PRs.
justinmclean commentedon Sep 8, 2026
I think only one skill is needed - the process is the same, with only a couple of exceptions. The differences above are correct, but not in that they apply to different groups of people. One is the PPMC reviewing the release, and the other is the IPMC reviewing the release.
potiuk commentedon Sep 9, 2026
Fine for me ;)
potiuk commentedon Sep 9, 2026
Question is - should we attempt to move it out of Magpie to Incubator/Comdev (and which one?) I am tempted to make an experiment with the release family to see how such "shared" stewardship of skill family would work.
docs(release): wire jvm_artefact_checks and jvm_digest_set into Step 6b
feat(tools): add maven-artifact-verify and wire JVM artefact checks i…
docs(release): wire jvm_artefact_checks and jvm_digest_set into Step 6b
feat(tools): add maven-artifact-verify and wire JVM artefact checks i…