Skip to content

[TRACKING] Apache Maka 0.2.0-incubating source release #2974

Open
Task
6 of 9 issues completed
Open
[TRACKING] Apache Maka 0.2.0-incubating source release#2974
Task
6 of 9 issues completed
Labels
staleNo qualifying activity within the lifecycle policy windowtrackingTracking or umbrella issue

Description

@Astro-Han
Astro-Han
opened on Aug 13, 2026
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:

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.

Pre-vote readiness checklist

Run this immediately before sending the podling vote. Every item is mechanical and independently checkable. Do not open a vote if any item fails.

  • The candidate tag v<version>-incubating-rc<rc> exists on apache/maka and points to the intended commit.
  • Required CI is completed/success for that exact commit. A newer main does not invalidate an existing RC.
  • Prepare ASF source candidate succeeded on that commit and produced the unsigned archive.
  • https://dist.apache.org/repos/dist/dev/incubator/maka/<version>-incubating-rc<rc>/ exists and contains exactly the archive, its .sha512, and its .asc.
  • The archive filename matches the candidate contract above.
  • https://dist.apache.org/repos/dist/dev/incubator/maka/KEYS is reachable and contains the public key that signed this candidate.
  • npm run release:asf:verify -- --artifact <staged-archive> --keys <published-KEYS> passes against the staged bytes.
  • The [DISCUSS] thread on dev@maka.apache.org has run and no mentor or PPMC member has objected to cutting this RC.

Verification checklist carried in the vote email

These are the properties the release is actually approved on. Every voter checks them against the exact candidate and states which checks they performed. They are not pre-vote gates.

- [ ] Download links work.
- [ ] Checksums and signatures are valid.
- [ ] LICENSE, NOTICE, and DISCLAIMER-WIP are present and accurate for these bytes.
- [ ] The source package contains no unexpected binary files.
- [ ] Source files carry ASF license headers, or DISCLAIMER-WIP discloses the gap.
- [ ] The source builds and its tests pass from the extracted archive.

Release path

  1. Send [DISCUSS] Release Apache Maka <version> (incubating) to dev@maka.apache.org.
  2. Build the candidate from an exact commit with Prepare ASF source candidate.
  3. Sign the downloaded candidate locally; create and push the signed tag.
  4. Stage the immutable candidate to ASF dist/dev.
  5. Run the pre-vote readiness checklist.
  6. Run the podling vote on dev@maka.apache.org — at least 72 hours, at least three PPMC +1, more +1 than -1.
  7. Summarize the result, then run the IPMC vote on general@incubator.apache.org — at least 72 hours, at least three binding +1, more binding +1 than binding -1.
  8. Promote the approved artifact to ASF dist/release, update the download page, and announce.

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

Exit checklist

  • The [DISCUSS] thread has run with no unresolved objection.
  • The pre-vote readiness checklist passes.
  • The podling vote passes.
  • The IPMC vote passes.
  • The approved source artifact is published to ASF dist/release and announced.

Completion of this checklist closes this issue.

Non-blocking parallel work

These do not gate the source release and are not approved by its vote. They may later be built from an approved source-release commit.

Work Issue Note
ASF source headers and audit gate #3271 Audit runs clean against the candidate; header completeness is disclosed by DISCLAIMER-WIP and checked by voters
Incubator branding on release surfaces #3272 Remaining items depend on the website and on artifacts that do not exist yet
Podling website at maka.apache.org #3404 Currently 404
Post-incubation GitHub/npm distribution status #3274 Pre-incubation GitHub Releases are already gone; the npm side remains
npm convenience artifact #3275 Sequenced after both votes by the product release checklist
Desktop convenience artifacts #3276 Blocked on #3414
ASF code-signing identities #3414 Release Managers named; INFRA-28301 and INFRA-28302 filed and waiting on Infra

Closed gates

References

简体中文

目标

追踪 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 的退出条件：

这些 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 有各自的分发义务。不能仅为了开发或安装方便，就把它们复制进源码候选包。

投票前就绪清单

在发出 podling 投票之前立即执行。每一项都是机械的、可独立核验的。任何一项不通过就不要开启投票。

  • 候选标签 v<version>-incubating-rc<rc> 已存在于 apache/maka，且指向预期的提交。
  • 该确切提交的必需 CI 为 completed/success。main 前进本身不会使既有 RC 失效。
  • Prepare ASF source candidate 在该提交上成功，并产出了未签名归档。
  • https://dist.apache.org/repos/dist/dev/incubator/maka/<version>-incubating-rc<rc>/ 已存在，且只包含归档、其 .sha512 和其 .asc。
  • 归档文件名符合上文的候选契约。
  • https://dist.apache.org/repos/dist/dev/incubator/maka/KEYS 可达，且包含签署本候选包的公钥。
  • npm run release:asf:verify -- --artifact <staged-archive> --keys <published-KEYS> 针对暂存字节通过。
  • dev@maka.apache.org 上的 [DISCUSS] 线程已经走过，没有导师或 PPMC 成员反对切出本 RC。

随投票邮件下发的验证清单

这些才是发布真正据以获批的性质。每位投票人针对确切候选包检查，并说明自己执行了哪些检查。它们不是投票前的门禁。

- [ ] Download links work.
- [ ] Checksums and signatures are valid.
- [ ] LICENSE, NOTICE, and DISCLAIMER-WIP are present and accurate for these bytes.
- [ ] The source package contains no unexpected binary files.
- [ ] Source files carry ASF license headers, or DISCLAIMER-WIP discloses the gap.
- [ ] The source builds and its tests pass from the extracted archive.

发布路径

  1. 向 dev@maka.apache.org 发送 [DISCUSS] Release Apache Maka <version> (incubating)。
  2. 用 Prepare ASF source candidate 从确切提交构建候选包。
  3. 在本地签署下载到的候选包；创建并推送已签名标签。
  4. 将不可变的候选包上传至 ASF dist/dev。
  5. 执行投票前就绪清单。
  6. 在 dev@maka.apache.org 上进行 podling 投票——至少 72 小时，至少 3 张 PPMC +1，且 +1 多于 -1。
  7. 汇总结果，然后在 general@incubator.apache.org 上进行 IPMC 投票——至少 72 小时，至少 3 张具约束力的 +1，且具约束力的 +1 多于具约束力的 -1。
  8. 将获批产物提升至 ASF dist/release，更新下载页，并发布公告。

RC 一旦进入投票，其字节即不可变。任何字节变更都需要新的 RC 编号和重新投票。

退出清单

  • [DISCUSS] 线程已走过，无未解决的反对意见。
  • 投票前就绪清单通过。
  • podling 投票通过。
  • IPMC 投票通过。
  • 获批的源码产物已发布至 ASF dist/release 并发出公告。

本清单完成即关闭本 issue。

非阻塞的并行工作

以下工作不构成源码发布的门槛，也不由其投票批准。它们此后可以从获批的源码发布提交构建。

工作 Issue 说明
ASF 许可头与审计门禁 #3271 审计针对候选包执行通过；许可头完整性由 DISCLAIMER-WIP 披露并由投票人检查
发布载体上的孵化器品牌标识 #3272 剩余各项依赖网站以及尚不存在的产物
maka.apache.org podling 网站 #3404 目前为 404
入孵后的 GitHub/npm 分发状态 #3274 入孵前的 GitHub Release 已全部消失；npm 侧仍待处理
npm convenience artifact #3275 按产品发布检查表排在两轮投票之后
Desktop convenience artifacts #3276 被 #3414 阻塞
ASF 代码签名身份 #3414 Release Manager 已确定；INFRA-28301 与 INFRA-28302 已提交，等待 Infra

已关闭的门槛

参考资料

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.

Activity

  1. Astro-Han commented on Aug 13, 2026

    @Astro-Han
    Astro-Han
    on Aug 13, 2026
    ContributorAuthor

    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 邮箱无关。只有落入上述两类的人才需要确认身份。

  2. Astro-Han
    added
    help wantedExtra attention is needed
    on Aug 13, 2026

  3. M4n5ter commented on Aug 13, 2026

    @M4n5ter
    M4n5ter
    on Aug 13, 2026
    Member

    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:

    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:

    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:

    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.

  4. Astro-Han commented on Aug 13, 2026

    @Astro-Han
    Astro-Han
    on Aug 13, 2026
    ContributorAuthor

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

  5. likun666661
    added a commit that references this issue on Aug 17, 2026

    docs: declare the bundled Geist webfonts in LICENSE (#3140)

    9607a86
  6. Joob1n
    added a commit that references this issue on Aug 18, 2026

    docs: add DISCLAIMER-WIP for podling releases

    7b3a58d
  7. Astro-Han
    added a commit that references this issue on Aug 18, 2026

    docs: add DISCLAIMER-WIP for podling releases (#3141)

    49f8675
  8. M4n5ter
    added sub-issues on Aug 20, 2026
  9. M4n5ter
    changed the title [-][TRACKING] Apache Incubator onboarding checklist[/-] [+][TRACKING] First Apache Maka (Incubating) release[/+] on Aug 20, 2026
  10. M4n5ter
    removed
    help wantedExtra attention is needed
    on Aug 20, 2026
  11. M4n5ter
    added sub-issues on Aug 20, 2026
  12. Astro-Han
    added the
    Task
    issue type on Aug 20, 2026

  13. Astro-Han commented on Aug 20, 2026

    @Astro-Han
    Astro-Han
    on Aug 20, 2026
    ContributorAuthor

    The gate table records status but not whether a gate blocks the first release. Proposing a layering below, because it materially shortens the critical path: not every open gate has to be closed before a candidate can be built and voted on. Mentors and the IPMC own the final call — this is a working proposal for how we sequence, not a determination.

    Must be complete before a candidate

    • G1 — the source cannot carry third-party material that is unaccounted for or incompatible.
    • G3 — LICENSE and NOTICE must accurately describe the exact artifact. This is the most common reason an incubator RC is rejected.
    • G6 — export classification is a legal obligation and is not something a disclaimer can defer.
    • G2 — without it there is no candidate to vote on: reproducible archive, SHA-512, signing, and a clean-archive build.

    Can ship disclosed under DISCLAIMER-WIP

    • G4 — incomplete ASF source headers are the textbook use of DISCLAIMER-WIP, and applying headers across the tree is the largest mechanical task on the list. It does not need to precede a first candidate.
    • G5 — the core incubating identification must be right; remaining website and download-surface polish can follow.

    Depends on a mentor decision

    • G7 — whether the post-incubation GitHub and npm artifacts must be remediated before the first release, or can be handled in parallel, is a policy judgement rather than something we can read off a process document.

    The distinction that matters

    DISCLAIMER-WIP covers work that is incomplete, not statements that are inaccurate. Missing ASF headers are disclosed and fine. A LICENSE that omits a third-party component is not incomplete, it is wrong, and no disclaimer repairs that. Both attribution gaps recorded on #3270 fall on the wrong side of that line and belong to the blocking set.

    Practical consequence

    The critical path is G1 + G2 + G3 + G6, not all seven. G4 — the heaviest gate by volume — can proceed in parallel with the vote rather than gating it. Only G1 → G3 is a real ordering dependency: what LICENSE must say follows from what G1 finds. G5, G6, and G7 are independent of each other and of G1.

    简体中文

    Gate 表记录了状态，但没有区分某个 gate 是否阻塞首次发版。下面提出一个分层，因为它能实质缩短关键路径：并非每个未关闭的 gate 都必须在构建和投票候选版本之前完成。最终判断属于 mentors 和 IPMC——这里只是关于如何排序的工作提案，不是结论。

    候选版本之前必须完成

    • G1 —— 源码不能包含未交代清楚或不兼容的第三方材料。
    • G3 —— LICENSE 和 NOTICE 必须准确描述确切的 artifact。这是孵化器 RC 被否决最常见的原因。
    • G6 —— 出口分类是法律义务，不是免责声明可以推迟的事项。
    • G2 —— 没有它就没有可供投票的候选：可重复归档、SHA-512、签名，以及干净归档的构建。

    可以在 DISCLAIMER-WIP 披露下发布

    • G4 —— ASF 源码 header 不完整正是 DISCLAIMER-WIP 的教科书用途，而在整个代码树上加 header 是清单中工作量最大的机械任务。它不需要先于第一个候选完成。
    • G5 —— 核心的孵化标识必须正确；网站和下载界面剩余的完善工作可以后续进行。

    取决于 mentor 决策

    • G7 —— 孵化后发布的 GitHub 和 npm artifacts 是必须在首次发版前补救，还是可以并行处理，属于政策判断，无法从流程文档中读出答案。

    关键区别

    DISCLAIMER-WIP 覆盖的是未完成的工作，不是不准确的陈述。缺失 ASF header 经过披露即可接受。而遗漏了某个第三方组件的 LICENSE 不是不完整，是错误，任何免责声明都无法弥补。#3270 记录的两处署名缺失都落在这条线的错误一侧，属于阻塞集合。

    实际影响

    关键路径是 G1 + G2 + G3 + G6，而非全部七项。G4——按工作量算最重的 gate——可以与投票并行推进，而不是卡住投票。真正的顺序依赖只有 G1 → G3：LICENSE 该写什么取决于 G1 查出了什么。G5、G6、G7 彼此独立，也独立于 G1。

  14. Astro-Han commented on Aug 22, 2026

    @Astro-Han
    Astro-Han
    on Aug 22, 2026
    ContributorAuthor
    English

    Which gates actually block the source release

    The IPMC votes on one thing: the Incubator source release. Separating what that vote requires from what the project wants available at the same time changes the critical path.

    Hard blockers — the IPMC will check these and a candidate fails without them

    Disclosed rather than blocking

    After source approval by definition

    Proposal

    This contradicts the current statement above that npm and Desktop are both required for the first release, so it is a proposal rather than a correction.

    Concentrate on G1 and G3 to make a source candidate votable. Let G4, G5, and G7 proceed in parallel under the disclaimer. Publish G8 and G9 after source approval, on their own timelines, rather than holding the source vote for them. Name the Release Managers now (#3414), since nothing external can start until the PPMC does.

    Whether DISCLAIMER-WIP adequately covers each disclosed item, and whether Desktop must ship with the first release, are decisions for the mentors, PPMC, and IPMC. This comment is analysis prepared with Claude Code, reviewed by the author before posting; it is not a determination.

    简体中文

    真正阻塞源码 release 的是哪几个 gate

    IPMC 投票的对象只有一个：Incubator 源码 release。把「投票所需」和「项目希望同时可用」分开之后，关键路径会变。

    硬阻塞——IPMC 必查，缺了候选就通不过

    属于已披露事项，而非阻塞

    按定义就在源码获批之后

    提议

    这与上文「npm 和 Desktop 都是第一次发版的必需交付」相左，因此是提议而不是更正。

    集中打通 G1 和 G3，让源码候选具备投票条件；G4、G5、G7 在 disclaimer 覆盖下并行推进；G8 和 G9 在源码获批之后按各自节奏发布，而不是让源码投票等它们。现在就指定 Release Managers（#3414）——在 PPMC 指定之前，外部流程一步也走不了。

    DISCLAIMER-WIP 是否充分覆盖每一项已披露事项，以及 Desktop 是否必须随第一次发版一起交付，属于 mentors、PPMC 和 IPMC 的决定。本评论是借助 Claude Code 准备、并由作者在发布前审阅的分析，不构成任何判断。

  15. Astro-Han
    added
    enhancementNew feature or request
    on Aug 23, 2026
  16. Astro-Han
    changed the title [-][TRACKING] First Apache Maka (Incubating) release[/-] [+][TRACKING] Apache Maka 0.2.0-incubating source release[/+] on Aug 27, 2026
  17. Astro-Han
    added a commit that references this issue on Aug 27, 2026

    fix(release): enforce ASF source candidate compliance (#3999)

    d27c02a
  18. Astro-Han
    removed
    enhancementNew feature or request
    on Aug 29, 2026

  19. Astro-Han commented on Sep 1, 2026

    @Astro-Han
    Astro-Han
    on Sep 1, 2026
    ContributorAuthor
    English

    Restructured the gates: mechanical before the vote, legal inside it

    The gate table treated incoming IP provenance, LICENSE/NOTICE accuracy, license headers, and branding as things to close before a candidate could be voted on. Checking that against how ASF projects actually run a source release, the checks were right but their position was wrong.

    Apache OpenDAL's release runbook is 595 lines covering the complete process. Its entire "Preparation" section asks the Release Manager to set up a GPG key. Searching it for ICLA, SGA, grant, clearance, provenance, or copyright returns nothing; LICENSE and NOTICE appear twice, one of which is a checkbox in the vote email. Their pre-vote readiness checklist is ten items, all mechanical: does the tag exist, is CI green, are the artifacts in dist/dev, is the KEYS URL reachable.

    The legal properties are verified by voters, against the exact candidate, during the vote. That is the design: independent verification by people casting binding votes is the check, and a pre-vote sign-off does not add to it.

    This issue now carries two lists instead of the gate table:

    • a pre-vote readiness checklist — mechanical, all independently checkable, run immediately before opening the vote;
    • the verification checklist carried in the vote email — the properties the release is actually approved on.

    Everything that does not gate the source release moved to a non-blocking table: #3271, #3272, #3274, #3275, #3276, #3404, #3414.

    Two gates proposed for closure

    Both are proposals, not determinations. Mentors and the IPMC own that call; if either reads differently, say so on the issue and we reopen rather than proceed.

    Where this leaves RC1

    With those two closed, steps 3 through 7 of the release path have no outstanding prerequisite. The candidate is built and reproducible, the Release Managers are named, and the signing key is published in the podling KEYS. What remains is operational: run the [DISCUSS] thread, push the signed tag, stage to dist/dev, and open the vote.

    One real gap before signing: KEYS currently contains one key. If wyt may sign as backup Release Manager, that public key needs to be added first, or voters cannot verify a candidate they sign.

    简体中文

    重构 gate：机械项放在投票前，法务项放在投票内

    原来的 gate 表把 incoming IP provenance、LICENSE/NOTICE 准确性、许可头、品牌标识都当成候选版本可投票之前必须关闭的事项。对照 ASF 项目实际执行源码发布的方式，这些检查本身没错，但位置错了。

    Apache OpenDAL 的发布手册有 595 行，覆盖完整流程。它整个「Preparation」章节只要求 Release Manager 配置好 GPG 密钥。全文搜索 ICLA、SGA、grant、clearance、provenance、copyright 均无命中；LICENSE 和 NOTICE 只出现两次，其中一次是投票邮件里的勾选框。他们的投票前就绪清单共十条，全是机械项：标签在不在、CI 是否为绿、产物是否已在 dist/dev、KEYS 链接是否可达。

    法务性质由投票人在投票过程中针对确切候选包核验。这是设计使然：投出具约束力票的人各自独立验证，这就是那道检查，投票前再签一次字并不增加任何东西。

    本 issue 现在用两份清单取代原来的 gate 表：

    • 投票前就绪清单——机械项，全部可独立核验，在开启投票前立即执行；
    • 随投票邮件下发的验证清单——发布真正据以获批的那些性质。

    所有不构成源码发布门槛的工作移入非阻塞表：#3271、#3272、#3274、#3275、#3276、#3404、#3414。

    提议关闭两个 gate

    两者都是提议，不是判定。判定权在导师和 IPMC；如有不同读法，请在对应 issue 说明，我们会重开而不是继续推进。

    RC1 现在的位置

    这两个关闭之后，发布路径第 3 到第 7 步没有未了结的前置。候选包已构建且可复现，Release Manager 已确定，签名密钥已发布在 podling KEYS 中。剩下的都是操作：走 [DISCUSS] 线程、推送已签名标签、上传到 dist/dev、开启投票。

    签名前有一个真实缺口：KEYS 目前只有一把密钥。如果 wyt 可能作为备份 Release Manager 签名，需要先把该公钥加入，否则投票人无法验证他签出的候选包。

    Drafted with help from Claude Code. I reviewed the final text and take responsibility for posting it.

  20. Astro-Han
    added
    trackingTracking or umbrella issue
    on Sep 17, 2026
  21. github-actions
    added
    staleNo qualifying activity within the lifecycle policy window
    on Oct 2, 2026

  22. github-actions commented on Oct 2, 2026

    @github-actions
    github-actionsbot
    on Oct 2, 2026 – with GitHub Actions

    This issue has had no human activity for 30 days and has been marked stale. It will be closed in 30 days unless someone comments.

    If the issue is still current, please confirm it against the latest main and add any information that would help move it forward. Assigned issues and issues labelled pinned are exempt from this policy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    staleNo qualifying activity within the lifecycle policy windowtrackingTracking or umbrella issue

    Type

    Task

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions