[TRACKING] First Apache Maka (Incubating) release

[Astro-Han]

English

Goal

Track the gates and execution sequence for the first Apache Maka (Incubating) release, version 0.2.0-incubating.

Sub-issues own implementation details. This issue records the current critical path, gate status, and exit conditions.

Release scope

The first release has two related tracks.

The ASF release is the Incubator source release: apache-maka-0.2.0-incubating-src.tar.gz. This is the artifact reviewed and voted on by the podling and the IPMC.

Product availability means users can install Maka through the maka-agent npm package and the macOS/Windows Desktop artifacts. These are convenience artifacts under ASF policy. They must be built from the same approved source-release commit, but they are not themselves the object of the ASF source-release vote.

Both tracks are required for the first usable release, but they have different sequencing and blockers.

Legal-file authority follows the actual bytes of each artifact:

• G3 covers the extracted ASF source candidate.
• G8 covers the published npm package.
• G9 covers the macOS and Windows Desktop artifacts.

Resolving the source candidate does not waive obligations carried only by a convenience artifact.

Current critical path

1. Build a fresh apache-maka-0.2.0-incubating-src.tar.gz from current main.
2. Review the exact candidate bytes against G3 and G4.
3. Confirm a qualified Release Manager through Discussion [DISCUSS] Release Managers for Apache Maka 0.2.0 #3595.
4. Create the 0.2.0-incubating-rc1 execution issue and prepare the podling vote.
5. Run the podling vote, followed by the IPMC vote.
6. After source approval, publish the npm and Desktop convenience artifacts from the approved commit.

ASF Apple Developer Program and Windows eSigner provisioning should run in parallel because those requests may take longer than the source-candidate review. The corresponding INFRA requests should identify the one or two Release Managers who will hold and operate the credentials.

Current status

Gate	Status	Exit condition	Tracking
G1: Incoming IP and provenance	No active project-side work; monitor for concrete objections	The current public best-effort record remains available. Any specific provenance, rights, or disclosure objection raised by a reviewer or voter is addressed before the vote proceeds	#3268; human-reviewed audit PR #2907; independent replacement PR #3456; #3293
G2: Source release mechanics	Complete	Reproducible source archive, SHA-512, signing and KEYS path, clean-archive build and tests, dist/dev runbook, and vote templates work	#3269; PR #3278; hotfix #3332
G3: Source-release legal files	Implementation complete; fresh 0.2.0 candidate review pending	The extracted 0.2.0 source candidate has accurate root LICENSE, NOTICE, and DISCLAIMER-WIP; all vendored, adapted, and generated inputs are identified and attributed; no Category X material or compiled third-party binaries are present	#3270; merged PRs #3325/#3565
G4: Source headers and release audit	Implementation complete; exact-candidate audit pending	The agreed ASF header policy is applied and the fail-closed release audit passes against the exact 0.2.0 source candidate presented for voting	#3271; merged PRs #3397/#3501/#3565
G5: Incubator branding	Core release branding complete; website follow-up is nonblocking	Repository and release-facing materials identify Apache Maka as incubating and distinguish the ASF source release from convenience artifacts. Website/download improvements continue separately	#3272; #3404; merged PRs #3391/#3262
G6: Export classification	Not applicable	Existing guidance records that the ASF cryptography notification process does not apply	#3273 (closed)
G7: Existing distribution remediation	Nonblocking follow-up	The active bundled-Git and repository publication paths are resolved. Historical GitHub/npm distribution inventory and any additional labeling may continue separately unless a reviewer identifies a concrete release issue	#3274; merged PR #3457
G8: npm convenience artifact	Repository implementation and 0.2.0 version update complete; release execution pending	After source approval, publish from the approved commit with the canonical disclaimer, artifact-specific LICENSE/NOTICE review, Category B/X review, project-controlled trusted publishing and 2FA, registry provenance, and Linux/macOS/Windows installation acceptance	#3275; merged PRs #3222/#3335/#3481/#3599
G9: Desktop convenience artifacts	Repository path and bundled Git resolved; signing, artifact review, and acceptance pending	Build from the approved commit; obtain ASF Apple Developer Program and Windows eSigner access; confirm no Category X content; complete artifact-specific legal files, signatures, hashes, and macOS/Windows acceptance	#3276; merged PRs #3457/#3599; #3414; #3222; Discussion #3595

G1 handling

The project has already made a reasonable best-effort attempt to establish the Bootstrap Contributor record:

• PR docs: close code origin audit #2907 contains the human-reviewed audit.
• PR fix(desktop): independently replace cursor values #3456 provides an independently contributed replacement.
• The current public disclosures remain available for release reviewers and voters.

There is no further proactive contributor outreach or speculative paperwork planned. Issue #3268 remains as historical evidence and a place to record a concrete objection, but it is not an active source-release blocker by itself.

If a reviewer or voter identifies a specific unresolved provenance, rights, or disclosure concern, that concern becomes actionable and must be addressed before proceeding.

G5 and G7 handling

Website work and the historical distribution inventory remain useful follow-ups, but neither should delay preparation or voting of an otherwise compliant 0.2.0 source candidate.

The bundled Git/Dugite distribution issue was resolved by PR #3457. Discussion #3411 concerns a possible future Gitoxide-backed capability and is not part of the first-release critical path.

Creating the release execution issue

Create the 0.2.0-incubating-rc1 execution issue when:

1. A fresh 0.2.0 source candidate has been built from current main.
2. G3 review passes against the extracted candidate.
3. G4 release audit passes against the same candidate.
4. A qualified Release Manager is confirmed.

G1, G5, and G7 do not require additional proactive work before creating the RC unless a reviewer raises a concrete release-blocking objection.

The execution issue should track:

• Candidate commit and immutable source-archive checksum.
• Release Manager and signing key.
• Podling vote.
• IPMC vote.
• ASF distribution publication.
• npm publication from the approved commit.
• macOS and Windows publication from the approved commit.
• Platform acceptance and final announcement.

Once a candidate enters a vote, its bytes are immutable. Any change requires a new RC number and a fresh vote.

Foundation already in place

• Apache Incubator entry on 2026-08-13.
• Repository moved to apache/maka.
• Podling status page and mailing lists established.
• Root LICENSE, NOTICE, and DISCLAIMER-WIP added by docs: add DISCLAIMER-WIP for podling releases #3141.
• CLI packages carry DISCLAIMER-WIP through fix(release): carry DISCLAIMER-WIP in the npm CLI tarball #3220.
• Bundled Git runtime and its Category X distribution path removed by refactor(release): stop distributing bundled Git #3457.
• Known source-candidate legal and provenance gaps addressed by fix: close source release legal provenance gaps #3565.
• Release version advanced to 0.2.0 by chore(release): set product version to 0.2.0 #3599.

These facts establish the release foundation but do not themselves constitute source-release approval.

Tracking rules

1. Use one sub-issue per independently reviewable outcome. Reuse an existing issue only when its exit condition is the same.
2. Every pull request on the release path links its sub-issue and states which exit condition it satisfies.
3. A related pull request does not make its author responsible for a wider legal, governance, or release scope.
4. Only mark a gate complete when its exit condition has been verified against the relevant artifact.
5. Once an RC enters a vote, any byte change requires a new RC and a fresh vote.

References

• Maka podling status
• Incubator release management
• ASF release policy
• Incubator npm distribution guide
• Incubator disclaimer policy
• ASF third-party license policy
• Release Manager discussion

简体中文

目标

追踪第一次 Apache Maka（孵化中）发版的门槛和执行顺序。本次版本确定为 0.2.0-incubating。

各个 sub-issue 负责具体实现；本 issue 只维护当前关键路径、gate 状态和退出条件。

发版范围

第一次发版包含两条相互关联的轨道。

ASF release 是 Incubator 源码发版：apache-maka-0.2.0-incubating-src.tar.gz。Podling 和 IPMC 审查、投票的对象是这个源码 artifact。

产品可用性指用户可以通过 maka-agent npm 包和 macOS/Windows Desktop artifacts 安装 Maka。根据 ASF 政策，它们属于 convenience artifacts，必须从获批源码发版的同一个 commit 构建，但它们本身不是 ASF 源码发版投票的对象。

两条轨道都是第一次可用发版的一部分，但执行顺序和阻塞项不同。

法律文件的 authority 跟随每个 artifact 的实际字节：

• G3 负责解压后的 ASF 源码候选。
• G8 负责实际发布的 npm 包。
• G9 负责 macOS 和 Windows Desktop artifacts。

源码候选完成闭环，不代表免除了 convenience artifact 自己携带的义务。

当前关键路径

1. 从当前 main 构建新的 apache-maka-0.2.0-incubating-src.tar.gz。
2. 针对这份候选包的确切字节完成 G3 和 G4 审查。
3. 通过 Discussion [DISCUSS] Release Managers for Apache Maka 0.2.0 #3595 确定一位合格的 Release Manager。
4. 创建 0.2.0-incubating-rc1 执行 issue，准备 podling 投票。
5. 完成 podling 投票，然后进行 IPMC 投票。
6. 源码获批后，从获批 commit 发布 npm 和 Desktop convenience artifacts。

ASF Apple Developer Program 和 Windows eSigner 的申请耗时可能长于源码候选审查，因此应当并行推进。对应的 INFRA 请求应写明实际持有和操作凭据的一至两位 Release Managers。

当前状态

Gate	状态	退出条件	跟踪项
G1：代码来源与知识产权输入	没有主动执行项；等待具体异议	当前公开的 best-effort 记录继续保留。发版审查者或投票者如果提出具体的来源、权利或披露问题，在继续投票前处理	#3268；人工审查 PR #2907；独立替换 PR #3456；#3293
G2：源码发版机制	已完成	可重复源码归档、SHA-512、签名与 KEYS 路径、干净归档构建和测试、dist/dev runbook 与投票模板可用	#3269；PR #3278；hotfix #3332
G3：源码 release 法律文件	实现已完成；待审查新的 0.2.0 候选包	解压后的 0.2.0 源码候选具备准确的根 LICENSE、NOTICE 和 DISCLAIMER-WIP；全部 vendored、adapted 和 generated 输入均已识别并署名；不含 Category X 材料或编译后的第三方二进制	#3270；已合并 PR #3325/#3565
G4：源码 headers 与发版审计	实现已完成；待针对确切候选包运行审计	约定的 ASF header 策略已经落实，fail-closed 发版审计针对提交投票的同一份 0.2.0 源码候选通过	#3271；已合并 PR #3397/#3501/#3565
G5：孵化器品牌	核心发版标识已完成；网站后续工作不阻塞发版	仓库和发版相关材料明确标识 Apache Maka 正在孵化，并区分 ASF 源码发版和 convenience artifacts。网站及下载页面可继续单独完善	#3272；#3404；已合并 PR #3391/#3262
G6：出口分类	不适用	已有指导记录 ASF 密码学通知流程不适用	#3273（已关闭）
G7：已有分发补救	非阻塞后续工作	当前 bundled Git 和仓库发布路径已经解决。历史 GitHub/npm 分发盘点及额外标注可以继续推进，除非审查者指出具体的发版问题	#3274；已合并 PR #3457
G8：npm convenience artifact	仓库实现和 0.2.0 版本更新已完成；待真实发版执行	源码获批后从获批 commit 发布；完成权威免责声明、npm artifact-specific LICENSE/NOTICE、Category B/X 审查、项目可控制的 trusted publishing 与 2FA、registry provenance，以及 Linux/macOS/Windows 安装验收	#3275；已合并 PR #3222/#3335/#3481/#3599
G9：Desktop convenience artifacts	仓库路径和 bundled Git 已解决；待签名、artifact 审查和验收	从获批 commit 构建；取得 ASF Apple Developer Program 和 Windows eSigner 权限；确认不含 Category X；完成 artifact-specific 法律文件、签名、hash 和 macOS/Windows 验收	#3276；已合并 PR #3457/#3599；#3414；#3222；Discussion #3595

G1 的处理方式

项目已经尽合理努力建立 Bootstrap Contributor 记录：

• PR docs: close code origin audit #2907 包含经过人工审查的审计。
• PR fix(desktop): independently replace cursor values #3456 提供了独立贡献的替换实现。
• 当前公开披露继续保留，供发版审查者和投票者查看。

目前不再主动联系 Bootstrap Contributors，也不再补充没有具体问题指向的材料。Issue #3268 继续作为历史证据和记录具体异议的地方，但它本身不再是一个主动的源码发版阻塞项。

如果审查者或投票者提出具体且尚未解决的来源、权利或披露问题，该问题才重新成为需要在继续发版前处理的执行项。

G5 和 G7 的处理方式

网站工作和历史分发盘点仍然有价值，但不应延误一份其他方面合规的 0.2.0 源码候选进入准备和投票流程。

PR #3457 已经解决 bundled Git/Dugite 分发问题。Discussion #3411 讨论的是未来可能采用的 Gitoxide 能力，不属于第一次发版的关键路径。

创建发版执行 issue 的条件

满足以下条件后，创建 0.2.0-incubating-rc1 执行 issue：

1. 已经从当前 main 构建新的 0.2.0 源码候选。
2. G3 针对解压后的候选包审查通过。
3. G4 发版审计针对同一份候选包通过。
4. 已经确定一位合格的 Release Manager。

除非审查者提出具体的发版阻塞异议，G1、G5 和 G7 不需要在创建 RC 前继续主动补充工作。

执行 issue 应跟踪：

• 候选 commit 和不可变的源码归档 checksum。
• Release Manager 和签名 key。
• Podling 投票。
• IPMC 投票。
• ASF distribution 发布。
• 从获批 commit 发布 npm。
• 从获批 commit 发布 macOS 和 Windows artifacts。
• 平台验收和最终公告。

候选进入投票后，其字节不可变。任何变化都需要新的 RC 序号和重新投票。

已经完成的基础工作

• 2026-08-13 进入 Apache Incubator。
• 仓库迁移到 apache/maka。
• Podling 状态页和邮件列表已经建立。
• docs: add DISCLAIMER-WIP for podling releases #3141 添加根目录 LICENSE、NOTICE 和 DISCLAIMER-WIP。
• fix(release): carry DISCLAIMER-WIP in the npm CLI tarball #3220 为 CLI packages 添加 DISCLAIMER-WIP。
• refactor(release): stop distributing bundled Git #3457 移除 bundled Git runtime 及其 Category X 分发路径。
• fix: close source release legal provenance gaps #3565 处理已知源码候选法律文件和来源问题。
• chore(release): set product version to 0.2.0 #3599 将发版版本更新为 0.2.0。

这些事实构成发版基础，但它们本身不代表源码发版已经获得批准。

追踪规则

1. 每个可独立审查的结果使用一个 sub-issue；只有退出条件相同时才复用已有 issue。
2. 发版路径上的每个 PR 关联其推进的 sub-issue，并说明满足哪个退出条件。
3. 相关 PR 不会让其作者自动承担更宽的法律、治理或发版范围。
4. 只有针对相应 artifact 验证退出条件后，才将 gate 标记为完成。
5. RC 进入投票后，任何字节变化都需要新的 RC 和重新投票。

参考资料

• Maka podling 状态
• Incubator 发版管理
• ASF 发版政策
• Incubator npm 分发指南
• Incubator 免责声明政策
• ASF 第三方许可证政策
• Release Manager 讨论

---

The 2026-08-23 revision was drafted with OpenAI Codex and reviewed by a human contributor before publication. It records the project's current release sequencing and implementation status; it does not replace release review or a podling/IPMC vote.

[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 有具体材料可供审阅。