[TRACKING] Apache Maka 0.2.0-incubating source release

[Astro-Han]

English

Goal

Track the Apache Maka 0.2.0-incubating source release from an exact commit through ASF approval and publication.

The single release authority is the source candidate apache-maka-0.2.0-incubating-src.tar.gz. Podling and IPMC voters review this exact archive. Everything in this issue is evaluated against its contents, provenance, and reproducibility.

Scope

This issue covers only the ASF source release:

1. Select an exact immutable commit.
2. Produce the source candidate, SHA-512 checksum, and detached signature.
3. Verify the extracted candidate's provenance, licensing, headers, disclaimer, branding, build, and tests.
4. Publish the candidate to ASF dist/dev and run the podling and IPMC votes.
5. Promote the approved source release to ASF dist/release and announce it.

The following are separate, nonblocking work and are not part of this source-release exit condition:

• npm convenience artifacts (release: publish an ASF-compliant npm convenience artifact #3275).
• Desktop convenience artifacts (release: publish ASF-compliant Desktop convenience artifacts #3276).
• Standalone CLI binaries or GitHub Release binary assets.
• Apple and Windows code-signing infrastructure (infra: obtain ASF code signing identities for Desktop artifacts #3414).
• Product installation, upgrade, and platform acceptance.
• Historical GitHub/npm distribution remediation (release: resolve post-incubation GitHub and npm distribution status #3274), unless review identifies a concrete problem in the source candidate.

These artifacts may later be built from an approved source-release commit, but the ASF source release does not wait for them and does not approve their bytes.

Source candidate contract

The candidate must:

• Identify one exact immutable commit and archive.
• Contain only source and repository material needed to build and test the release.
• Exclude installed dependencies and local workspace state, including node_modules, installed runtimes, caches, and external toolchains.
• Exclude compiled third-party executables and benchmark/runtime toolchains that are not needed to build or test Maka.
• Contain no bundled Category X material, including GPL, LGPL, or AGPL dependencies.
• Record the source, license, and required attribution for every third-party, adapted, generated, or non-text input included in the archive.
• Carry accurate root LICENSE, NOTICE, and DISCLAIMER-WIP files for its exact contents.
• Pass all release checks against the extracted archive presented for voting, not merely against the Git checkout.

Runtime dependencies and convenience artifacts have their own distribution obligations. They must not be copied into the source candidate simply to make development or installation more convenient.

Immediate work

1. Exclude the DeepSeek Harness runtime toolchain from the source candidate. Its nested lockfile reaches sharp/libvips packages licensed under LGPL, and that toolchain is not required to build or test this release.
2. Add a fail-closed recursive audit of every manifest and lockfile included in the archive, including nested workspaces and toolchains.
3. Inventory every non-text file in the archive: reject compiled executables and require provenance for images, generated assets, and fixtures.
4. Build a fresh candidate from current main and review the exact extracted bytes before creating an RC.

Current source-release gates

Gate	Status	Exit condition	Tracking
Incoming IP and provenance	Monitor concrete objections	The public best-effort record remains available; any specific provenance, rights, or disclosure objection raised during review is resolved	#3268; PR #2907; PR #3456; #3293
Source candidate workflow	Complete	Reproducible source archive, SHA-512, signature/KEYS path, clean-archive build and tests, dist/dev runbook, and vote templates are available	#3269; PR #3278; #3332
Candidate contents and legal files	Reopen exact-candidate review	The extracted candidate contains only admissible source material and has accurate LICENSE, NOTICE, DISCLAIMER-WIP, provenance, and attribution	#3270; PR #3325; PR #3565
Headers and release audit	Exact-candidate audit pending	Header policy and the fail-closed recursive release audit pass against the exact archive	#3271; PR #3397; PR #3501; PR #3565
Incubator branding	Core work complete	Repository and source-release materials identify Apache Maka as incubating	#3272; #3404; PR #3391; PR #3262
Export classification	Complete / not applicable	Existing guidance records that the ASF cryptography notification process does not apply	#3273
Release Manager	Pending	A qualified Release Manager and signing key are confirmed	Discussion #3595

Closed implementation issues remain part of the evidence trail; they do not replace verification of the exact candidate.

Release path

1. Confirm the Release Manager and signing key.
2. Build apache-maka-0.2.0-incubating-src.tar.gz from an exact commit.
3. Run the complete archive-bound legal, provenance, header, build, and test review.
4. Create the 0.2.0-incubating-rc1 execution issue with the commit, archive checksum, signature, and review results.
5. Publish the immutable candidate to ASF dist/dev.
6. Run the podling vote.
7. Run the IPMC vote.
8. Promote the approved source artifact to ASF dist/release and announce it.

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

Exit checklist

• One qualified Release Manager and signing key are confirmed.
• The candidate is bound to one exact commit and SHA-512 checksum.
• Only source needed to build and test the release is present.
• No Category X material or compiled third-party executable is bundled.
• Recursive manifest/lockfile and non-text provenance audits pass.
• Extracted-candidate LICENSE, NOTICE, and DISCLAIMER-WIP are accurate.
• Header/RAT, clean build, and focused tests pass against the extracted candidate.
• Podling vote passes.
• IPMC vote passes.
• The approved source artifact is published to ASF dist/release and announced.

Completion of this checklist closes #2974. npm, Desktop, signing, product acceptance, and historical distribution work continue in their own issues.

References

• Maka podling status
• Incubator release management
• ASF release policy
• Incubator disclaimer policy
• ASF third-party license policy

简体中文

目标

追踪 Apache Maka 0.2.0-incubating 源码版本从一个确切 commit 到 ASF 批准和发布的完整过程。

唯一的发版权威是源码候选包 apache-maka-0.2.0-incubating-src.tar.gz。Podling 和 IPMC 投票者审查的是这份确切归档；本 issue 的所有判断均以它的实际内容、来源和可复现性为准。

范围

本 issue 只覆盖 ASF 源码发布：

1. 选定一个确切且不可变的 commit。
2. 生成源码候选包、SHA-512 checksum 和 detached signature。
3. 针对解压后的候选包验证来源、许可证、headers、免责声明、品牌标识、构建和测试。
4. 将候选包发布到 ASF dist/dev，完成 podling 和 IPMC 投票。
5. 将获批源码版本提升到 ASF dist/release 并公告。

以下工作独立推进，不阻塞本源码版本，也不属于本 issue 的退出条件：

• npm convenience artifacts（release: publish an ASF-compliant npm convenience artifact #3275）。
• Desktop convenience artifacts（release: publish ASF-compliant Desktop convenience artifacts #3276）。
• 独立 CLI 二进制或 GitHub Release 二进制附件。
• Apple 和 Windows 代码签名基础设施（infra: obtain ASF code signing identities for Desktop artifacts #3414）。
• 产品安装、升级和平台验收。
• 历史 GitHub/npm 分发补救（release: resolve post-incubation GitHub and npm distribution status #3274），除非审查发现它对本次源码候选造成了具体问题。

这些 artifact 后续可以从获批源码版本的 commit 构建，但 ASF 源码发布不等待它们，也不批准它们的实际字节。

源码候选契约

候选包必须：

• 对应一个确切且不可变的 commit 和 archive。
• 只包含构建和测试本版本所需的源码及仓库材料。
• 排除已安装依赖和本地 workspace 状态，包括 node_modules、已安装 runtime、cache 和外部 toolchain。
• 排除编译后的第三方可执行文件，以及构建或测试 Maka 不需要的 benchmark/runtime toolchain。
• 不捆绑任何 Category X 材料，包括 GPL、LGPL 或 AGPL 依赖。
• 记录归档内每个第三方、改编、生成或非文本输入的来源、许可证和必要署名。
• 根目录 LICENSE、NOTICE 和 DISCLAIMER-WIP 必须准确对应候选包的实际内容。
• 所有发版检查必须针对提交投票的解压后归档运行，而不只是针对 Git checkout。

Runtime 依赖和 convenience artifact 有各自的分发义务。不能仅为了开发或安装方便，就把它们复制进源码候选包。

当前优先工作

1. 从源码候选包排除 DeepSeek Harness runtime toolchain。其嵌套 lockfile 可达采用 LGPL 许可证的 sharp/libvips packages，而且该 toolchain 并非构建或测试本版本所需。
2. 增加 fail-closed 递归审计，覆盖归档内每个 manifest 和 lockfile，包括嵌套 workspace 与 toolchain。
3. 盘点归档内所有非文本文件：拒绝编译后的 executable，并要求图片、生成资源和 fixture 具备来源记录。
4. 从当前 main 构建新的候选包，并在创建 RC 前审查解压后的确切字节。

当前源码发布门槛

Gate	状态	退出条件	跟踪项
代码来源与知识产权输入	等待具体异议	公开的 best-effort 记录继续保留；审查中提出的任何具体来源、权利或披露异议均已解决	#3268；PR #2907；PR #3456；#3293
源码候选工作流	已完成	可重复源码归档、SHA-512、签名/KEYS 路径、干净归档构建和测试、dist/dev runbook 与投票模板可用	#3269；PR #3278；#3332
候选内容及法律文件	重新进行确切候选审查	解压后的候选只含允许发布的源码材料，并具备准确的 LICENSE、NOTICE、DISCLAIMER-WIP、来源及署名	#3270；PR #3325；PR #3565
Headers 与发版审计	待审计确切候选	Header 策略和 fail-closed 递归发版审计针对确切归档通过	#3271；PR #3397；PR #3501；PR #3565
孵化器品牌	核心工作已完成	仓库及源码发布材料明确标识 Apache Maka 正在孵化	#3272；#3404；PR #3391；PR #3262
出口分类	已完成／不适用	现有指导记录 ASF 密码学通知流程不适用	#3273
Release Manager	待确认	已确定合格的 Release Manager 和 signing key	Discussion #3595

已经关闭的实现 issue 继续作为证据保留，但不能替代对确切候选包的验证。

发布路径

1. 确定 Release Manager 和 signing key。
2. 从确切 commit 构建 apache-maka-0.2.0-incubating-src.tar.gz。
3. 针对归档完成法律、来源、header、构建和测试审查。
4. 创建 0.2.0-incubating-rc1 执行 issue，记录 commit、archive checksum、signature 和审查结果。
5. 将不可变候选包发布到 ASF dist/dev。
6. 进行 podling 投票。
7. 进行 IPMC 投票。
8. 将获批源码 artifact 提升到 ASF dist/release 并公告。

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

退出清单

• 已确定一位合格的 Release Manager 和 signing key。
• 候选包绑定一个确切 commit 和 SHA-512 checksum。
• 归档只包含构建和测试本版本所需的源码。
• 未捆绑 Category X 材料或编译后的第三方可执行文件。
• 递归 manifest/lockfile 审计和非文本来源审计通过。
• 解压后候选包的 LICENSE、NOTICE 和 DISCLAIMER-WIP 准确。
• Header/RAT、干净构建和聚焦测试针对解压后的候选包通过。
• Podling 投票通过。
• IPMC 投票通过。
• 获批源码 artifact 已发布到 ASF dist/release 并公告。

完成本清单即可关闭 #2974。npm、Desktop、签名、产品验收和历史分发工作继续在各自 issue 中推进。

参考资料

• Maka podling 状态
• Incubator 发版管理
• ASF 发版政策
• Incubator 免责声明政策
• ASF 第三方许可证政策

---

This revision was drafted with OpenAI Codex and reviewed by a human contributor before publication. It defines the source-release scope and current audit findings; 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 有具体材料可供审阅。