[TRACKING] First Apache Maka (Incubating) release

[Astro-Han]

English

Goal

Track the gates for the first Apache Maka (Incubating) release. Sub-issues own implementation; this issue records gate status and exit conditions only.

Scope of the first release

Two deliverables ship together, on separate tracks.

The ASF release is the Incubator source release: apache-maka-<version>-incubating-src.tar.gz, carrying DISCLAIMER-WIP while its disclosed items stay open. It is what the podling and IPMC vote on.

Product availability means users can install Maka: the maka-agent npm package and the macOS/Windows Desktop artifacts. Under ASF policy these are convenience artifacts rather than part of the release, and they must be built from the approved source release at the same version and commit. That is a policy classification, not a reason to defer them — both are required for the first release.

The two tracks gate differently. Source approval is blocked by G1, G3, G4, G5, and G7. Product availability is blocked by G8 and G9. Desktop additionally cannot ship until bundled Git via Dugite (GPLv2, Category X) is removed and the ASF signing identities are provisioned; DISCLAIMER-WIP cannot waive the former, and project-owned credentials cannot substitute for ASF signing authority. These independent prerequisites are tracked in #3411 and #3414.

Status

Gate	Status	Exit condition	Execution issue
G1: Incoming IP and provenance	Blocked	Human contributor review, contributor confirmations, SGA/ICLA coverage, and the required mentor/ASF determination are complete	#3268; audit PR #2907; #3293
G2: Source release mechanics	Complete	Reproducible source archive, SHA-512, signing/KEYS path, clean-archive build and tests, dist/dev runbook, and vote templates work	#3269; PR #3278; hotfix #3332
G3: Release legal files	Blocked	The source artifact has audited LICENSE/NOTICE contents and no Category X material	#3270; PR #3325
G4: Source headers and RAT	In progress	The agreed ASF header policy is applied and an automated release audit passes against the extracted archive	#3271
G5: Incubator branding	In progress	Repository, README, and website/download surfaces identify Apache Maka as incubating and distinguish source from convenience artifacts	#3272; #3404; PR #3391; PR #3262
G6: Export classification	Not applicable	Mentor guidance is that the ASF cryptography notification process does not apply	#3273 (closed)
G7: Existing distribution remediation	Inventory can start now; disposition needs mentors	Post-incubation GitHub/npm releases and the bundled-Git binary path are labeled, remediated, or otherwise resolved	#3274
G8: npm convenience artifact	Repository implementation complete; external configuration and release execution pending	Published from the approved source-release commit after approval; canonical disclaimer, explicit mentor/ASF Brand package-name confirmation, G3 review, independently operable PPMC trusted-publishing/2FA controls, registry provenance, and platform acceptance pass	#3275; merged PRs #3222/#3335/#3481; three npm maintainers have write access
G9: Desktop convenience artifacts	Blocked on bundled Git (#3411) and ASF signing identities (#3414)	No Category X content; ASF Apple Developer Program and eSigner access provisioned; artifact-specific legal files/signatures/hashes and platform acceptance complete	#3276; #3411; #3414; #3222

Create the release execution issue for a specific <version>-incubating-rc<rc> once G1, G3, G4, G5, and G7 are release-ready. npm and Desktop publication follows source approval and is tracked in the same execution issue.

Foundation already in place: incubation on 2026-08-13, repository at apache/maka, podling status page and mailing lists, root LICENSE/NOTICE/DISCLAIMER-WIP (#3141), and DISCLAIMER-WIP in CLI packages (#3220). None of that implies release approval.

Tracking rules

1. One sub-issue per independently reviewable outcome. Reuse an existing issue only when its exit condition is identical.
2. Every pull request on the release path links its sub-issue and states which exit condition it satisfies.
3. A related PR does not make its author responsible for a wider legal, governance, or release scope. An unassigned blocker is still a blocker.
4. Once a candidate enters a vote its bytes are immutable; any change needs a new RC number and a fresh vote.

References

• Maka podling status
• Incubator release management
• ASF release policy
• Incubator npm distribution guide
• Incubator disclaimer policy
• Apache OpenDAL incubating npm workflow
• ASF third-party license policy

简体中文

目标

追踪第一次 Apache Maka（孵化中）发版的各项门槛。Sub-issues 负责实现细节；本 issue 只记录 gate 状态与退出条件。

第一次发版的范围

两项交付一起发布，但走两条不同的轨道。

ASF release 是 Incubator 源码 release：apache-maka-<version>-incubating-src.tar.gz，在披露事项仍然开放期间保留 DISCLAIMER-WIP。它是 podling 和 IPMC 投票的对象。

产品可用性指用户装得上 Maka：maka-agent npm 包和 macOS/Windows Desktop artifacts。在 ASF 政策下它们是 convenience artifacts 而不是 release 的组成部分，必须由获批源码 release 以相同版本和 commit 构建。这只是政策上的归类，不是推迟它们的理由——两者都是第一次发版的必需交付。

两条轨道的阻塞项不同。源码获批被 G1、G3、G4、G5、G7 阻塞；产品可用性被 G8、G9 阻塞。Desktop 还必须先移除通过 Dugite 捆绑的 Git（GPLv2，Category X），并取得 ASF 的平台签名身份；DISCLAIMER-WIP 不能豁免前者，项目自有凭据也不能替代 ASF 签名 authority。这两个相互独立的前置项分别由 #3411 和 #3414 追踪。

当前状态

Gate	状态	退出条件	执行 issue
G1：代码来源与知识产权输入	阻塞	完成人工贡献负责人审查、贡献者确认、SGA/ICLA 覆盖，以及所需的 mentor/ASF 判断	#3268；审计 PR #2907；#3293
G2：源码发版机制	已完成	可重复源码归档、SHA-512、签名/KEYS 路径、干净归档构建与测试、dist/dev runbook 和投票模板可用	#3269；PR #3278；hotfix #3332
G3：发行包法律文件	阻塞	源码 artifact 具备经过审计的 LICENSE/NOTICE，且无 Category X 材料	#3270；PR #3325
G4：源码 headers 与 RAT	进行中	落实约定的 ASF header 策略，自动化发版审计对解压后的归档通过	#3271
G5：孵化器品牌	进行中	仓库、README 和网站/下载界面一致标识 Apache Maka 正在孵化，并区分源码与 convenience artifacts	#3272；#3404；PR #3391；PR #3262
G6：出口分类	不适用	依 mentor 指导，ASF 密码学通知流程不适用	#3273（已关闭）
G7：已有分发补救	盘点可立即开始；处置需 mentors 决定	按指导标注、补救或以其他方式解决进入孵化器后的 GitHub/npm 版本及 bundled Git 二进制路径	#3274
G8：npm convenience artifact	仓库实现已完成；外部配置与真实发版执行待完成	源码获批后从同一 commit 发布；权威免责声明、mentors/ASF Brand 对包名的明确认可、G3 审查、PPMC 可独立操作的 trusted-publishing/2FA 控制、registry provenance 与平台验收通过	#3275；已合并 PR #3222/#3335/#3481；已有三位 npm maintainers 持有 write access
G9：Desktop convenience artifacts	阻塞于 bundled Git（#3411）和 ASF 签名身份（#3414）	不含 Category X；取得 ASF Apple Developer Program 与 eSigner 权限；完成针对 artifact 的法律文件、签名/hash 和平台验收	#3276；#3411；#3414；#3222

当 G1、G3、G4、G5、G7 具备发版条件后，为具体的 <version>-incubating-rc<rc> 创建发版执行 issue。npm 和 Desktop 的发布在源码获批之后进行，并在同一个执行 issue 中跟踪。

已完成的基础工作：2026-08-13 进入孵化器、仓库迁移到 apache/maka、podling 状态页与邮件列表、根目录 LICENSE/NOTICE/DISCLAIMER-WIP（#3141），以及 CLI 包携带 DISCLAIMER-WIP（#3220）。这些都不等于 release 获得批准。

追踪规则

1. 每个可独立审查的结果保留一个 sub-issue；只有退出条件完全相同时才复用现有 issue。
2. 发版路径上的每个 PR 必须关联其推进的 sub-issue，并说明满足了哪个退出条件。
3. 相关 PR 不会让其作者承担更宽的法律、治理或发版范围。Unassigned blocker 仍然是 blocker。
4. 候选进入投票后其字节不可变；任何变化都需要新的 RC 序号和重新投票。

参考资料

• Maka podling 状态
• Incubator 发版管理
• ASF 发版政策
• Incubator npm 分发指南
• Incubator 免责声明政策
• Apache OpenDAL 孵化期 npm workflow
• ASF 第三方许可证政策

---

The 2026-08-21 revision separates the ASF release track from the product-availability track and was prepared with Claude Code; it must be reviewed by a human contributor of record. Release, licensing, and provenance conclusions remain with the PPMC, mentors, IPMC, and ASF Legal Affairs as applicable.

[Astro-Han]

Thanks for the pushback on the ICLA item — it was scoped too broadly and I have edited the description above. Recording the reasoning here so the correction is visible.

ICLAs are not required from every commit author. Per the ASF Contributor License Agreements page, ICLAs are required from project maintainers (committers) and from anyone making a large contribution; smaller contributions are made under clause 5 of the Apache-2.0 license and need no paperwork at all.

The Incubator IP Clearance guide adds the distinction for material contributors:

• material contributors who join the podling → ICLA
• material contributors who do not join the podling → SGA instead
• everyone else → no paperwork

Two timing points from the same guide: paperwork does not need to be complete before the code import, but the provenance of all code we intend to release must be established before our first release. So this is a pre-release gate, not a pre-transfer one.

What that means concretely for us: confirm the initial committer list and collect their ICLAs, confirm SGA coverage, and then review only the highest-volume contributors who are not on that list. The long tail needs nothing. For reference, 33 of the 56 distinct author emails have 5 or fewer commits, and contribution volume is heavily concentrated in the top handful.

Also worth correcting: I previously suggested @users.noreply.github.com addresses need mapping to real identities. That is not a problem in itself — ICLAs are matched by signer name and Apache ID, not by commit email. Identity only needs confirming for people who fall into one of the two categories above.

中文对照

感谢指出 ICLA 那条的问题 —— 原表述范围写宽了，上方正文已修订。这里记录一下依据，便于后续查阅。

并非所有 commit 作者都需要签 ICLA。 按 ASF Contributor License Agreements 页面，需要签 ICLA 的是项目 maintainer（即 committer），以及做出**实质性（large）**贡献的人；较小的贡献适用 Apache-2.0 第 5 条，完全不需要文书。

孵化器 IP Clearance guide 对 material contributor 作了进一步区分：

• 加入 podling 的实质性贡献者 → 签 ICLA
• 不加入 podling 的实质性贡献者 → 改为需要 SGA
• 其余贡献者 → 无需任何文书

同一份指南里还有两个时间点：代码导入前不要求文书齐备；但首次发布前，必须理清所有待发布代码的权属来源。所以这是发版前的门槛，不是 transfer 前的。

对我们的具体含义：确定初始 committer 名单并收齐其 ICLA，确认 SGA 覆盖范围，然后只需核对不在该名单中、贡献量靠前的少数人。长尾贡献者无需处理。作为参考，56 个不同提交者邮箱中有 33 个的提交数不超过 5 个，贡献量高度集中在头部少数人。

另外一处需要更正：我此前提到 @users.noreply.github.com 邮箱需要对应到真实身份，这本身并不构成问题 —— ICLA 是按签署人姓名和 Apache ID 匹配的，与 commit 邮箱无关。只有落入上述两类的人才需要确认身份。

[M4n5ter]

I did a first-pass provenance triage against the current repository contributor history and the Initial Committers listed in the Maka proposal.

Based on GitHub's current contributor statistics, the 7 Initial Committers account for roughly 89% of the recorded contributions. This suggests that the initial provenance review can probably focus on a relatively small number of non-initial contributors rather than treating every historical commit author as requiring an ICLA.

This is also consistent with the ASF's current guidance.

The ASF Contributor Agreements wording was updated in February 2026 (LEGAL-704). The current ASF guidance states that small contributions are made under Apache-2.0 Clause 5, while project maintainers and contributors making large contributions are expected to submit an ICLA:

• ASF Contributor Agreements
• ASF Licensing FAQ — provenance of ASF source code

For an existing codebase entering the Incubator, the rules are slightly more specific. The Podling IP Clearance guide says that where material contributors are joining as initial contributors, their CLAs are generally sufficient; where material contributors are not joining as initial contributors, or where additional corporate entities may hold rights, an SGA may be required instead. The guide also explicitly recommends consulting the mentors, general@incubator.apache.org, or Apache Legal for the circumstances of the specific podling:

• Podling IP Clearance

The Initial Code Import guide similarly says that, for code composed of patches from individual contributors, initial import can proceed once the major contributors by volume have completed ICLAs or SGAs:

• Initial Code Import

With that in mind, I suggest we start by reviewing the following non-initial contributors:

• liugddx
• me2seeks
• Nyvo-io
• Colafornia
• sunheyi6
• ARE404
• UncertaintyDeterminesYou4ndMe
• GabrielDrapor
• zhiiw
• somewan820

Among them, Nyvo-io, Colafornia, sunheyi6, GabrielDrapor, and zhiiw are also explicitly mentioned in the proposal as repeat contributors/module owners. Several of the others have feature-level contributions substantial enough that they are worth reviewing even if their raw commit counts are not especially high.

This should be treated only as a triage list, not a determination that every person above needs an ICLA or SGA. Commit count alone does not establish materiality or copyright ownership.

For each candidate, I think we need to establish:

1. whether their contribution is material to the codebase we intend to import/release;
2. whether the relevant rights are held by the individual or potentially by an employer/other entity; and
3. whether the contributor is joining the podling.

Once those facts are known, the mentors/IPMC can determine whether the relevant provenance is already sufficient under Apache-2.0 Clause 5, or whether an ICLA, SGA, CCLA, or some other action is needed.

For the long tail of small contributions, we should not automatically request an ICLA merely because someone appears in git log. We should first determine whether any additional paperwork is actually required under the ASF provenance/IP-clearance rules.

[Astro-Han]

Cross-checked your triage list against contribution volume measured by changed lines (git log --numstat) rather than commit count. The two metrics diverge for contributors who made few but large commits, so a handful of people fall above your threshold without appearing on the list.

Taking GabrielDrapor (~3.9k added lines, the lowest entry on your list) as the cutoff, these are also above it:

Contributor	Added lines
Mingqwqqaq	~19.7k
Thinkya1	~12.1k
Helck	~6.0k
ACMerJuyu	~5.9k
kunkunzhishan	~4.1k

Mingqwqqaq is higher than every entry currently on the list, so it is worth adding regardless of which metric we settle on.

This is not a correction of your list — commit count and changed lines are both reasonable proxies and neither establishes materiality on its own, as you noted. I would suggest we use changed lines as the primary ordering simply because it is closer to "how much of the code we are importing came from this person", and keep the same caveat: this is triage input, not a determination.

Your three-point framework for each candidate looks right to me. Suggest we work through it in volume order and record the outcome per person, so the mentors have something concrete to review.

中文对照

我按改动行数（git log --numstat）而非提交次数，对你的 triage 名单做了一次交叉核对。两种口径对"提交次数少但单次改动大"的贡献者会给出不同结果，因此有几位在门槛之上的人未出现在名单中。

以 GabrielDrapor（约 3.9k 新增行，你名单中的最低者）作为门槛，以下几位同样在其之上：

贡献者	新增行数
Mingqwqqaq	约 19.7k
Thinkya1	约 12.1k
Helck	约 6.0k
ACMerJuyu	约 5.9k
kunkunzhishan	约 4.1k

其中 Mingqwqqaq 高于名单上现有的所有人，无论最终采用哪种口径，都值得纳入。

这并不是对你名单的否定 —— 提交次数与改动行数都是合理的近似指标，且正如你所指出的，两者单独都不足以确定实质性。建议以改动行数作为主排序口径，理由仅仅是它更接近"我们将要导入的代码中有多少出自此人"，同时保留同样的前提：这只是 triage 输入，不构成判定。

你提出的三点判定框架我认为是对的。建议按改动量顺序逐个走一遍，并逐人记录结论，以便 mentor 有具体材料可供审阅。