2026-06-01 ~ 2026-06-07
讨论主要围绕 Kafka 4.4.0 的发布时间表及 KIP 冻结日期展开。版本管理者 Omnia 提出了两个备选方案，社区通过投票最终倾向于方案 1（KIP 冻结定于 7 月 8 日，发布目标为 9 月 9 日），以平滑过渡到每年 3 个版本的新节奏。
@Matthias J. Sax: 建议不要过度压缩发布时间表，倾向于将 KIP 冻结推迟至 7 月初，以保持每年 3 个版本的发布目标。
@Omnia Ibrahim: 作为发布经理提出了两个具体方案：方案 1 推迟几周发布（9 月），方案 2 推迟至 10 月发布，并分析了两者对后续版本的影响。
@Chia-Ping Tsai: 支持方案 1，认为该方案能让社区无缝过渡到新的年度发布节奏，并修正了 4.5.0 代码冻结日期的计算。
初步结论是采用方案 1，即 KIP 冻结日期为 2026 年 7 月 8 日，发布目标为 2026 年 9 月 9 日。下一步将由发布经理确认并更新发布计划。
讨论主要围绕 KIP-1238 为 TopologyTestDriver 引入多分区支持的设计方案，重点探讨了 Builder 模式的实现细节、向后兼容性及分区路由逻辑。双方已就引入独立 Builder 类、移除显式模式切换方法以及修正默认分区值等关键问题达成共识。
@Matthias J. Sax: 建议采用独立的 Builder 类，并提议将默认分区值设为 -1 以避免路由歧义，同时主张 Builder 应仅用于多分区模式以简化用户理解。
@Sébastien Viale: 同意采纳 Builder 模式和默认分区值 -1 的建议，并提出多分区模式由分区数隐式启用，旧构造函数的弃用将延后处理。
初步确定引入 TopologyTestDriverBuilder 类，并将默认分区值定为 -1；下一步将更新 KIP 文档以落实这些修改。
本次讨论主要确认了 Kafka 网站文档中 `generated` 目录支持新旧两种路径（`static/` 和 `content/`）且均能正常工作。针对 4.2 版本的特殊处理，开发者解释了因该版本文件重复存在而引入了排除配置，并在此 PR 中保持其原状。
@mimaison: 询问为何 `generated` 仅在 `static` 下仍能工作，以及为何 4.2 版本被视为特例。
@muralibasani: 确认系统支持新旧两种路径方式，发布经理可选择其一；解释 4.2 版本因同时存在真实文件和空存根，需通过 `excludeFiles` 配置防止错误路由。
讨论澄清了路径迁移的技术细节和 4.2 版本的特殊处理逻辑，消除了对兼容性的疑虑。
本讨论主要围绕 KIP-1321 展开，旨在为 StreamPartitioner 增加 Headers 支持以允许基于头信息的自定义分区。Matthias 建议弃用旧方法以便在 AK 5.0 移除，作者 Uladzislau 采纳该建议并更新了提案。随后 Uladzislau 启动了投票流程，Alieh 在最后提出了关于 Lambda 兼容性和 Headers 不可变性的补充建议。
@Matthias J. Sax: 建议弃用现有的 `partitions(...)` 方法，以便在 AK 5.0 中移除，并建议新方法不提供默认实现。
@Uladzislau Blok: 同意弃用旧版本方法，认为这能给用户留出足够的更新时间，并已更新 KIP。
@Alieh Saeedi: 建议在兼容性部分补充 Lambda 分区器的注意事项，并明确 Headers 在分区器中应为只读（不可变）。
作者已采纳弃用建议并更新了 KIP，且已启动投票线程；后续收到了关于文档细节的补充建议。
讨论主要围绕 KIP-1279 集群镜像功能的状态管理机制改进和消费者数据丢失风险。作者提议废弃基于主题配置后缀的方法，转而使用一等元数据记录来跟踪镜像主题状态变更，以提升设计的优雅性。同时，参与者确认了防止数据丢失的优先级，并认可了同步偏移量的计算公式。
@Federico Valeri: 提议用新的元数据记录替代主题配置后缀方式来管理镜像状态，并更新了关于消费者数据丢失风险的段落。
@Luke Chen: 认同数据丢失比重新处理更严重，支持提议的同步偏移量计算公式。
@Andrew Schofield: 赞赏状态管理的改进，但请求补充关于 Fetch RPC 和 Leader Epochs 的图表，并指出了 Share Group Offset 同步相关的 RPC 缺失及 EOS 安全性隐患。
初步结论是采纳新的元数据记录方案进行状态管理；下一步行动包括更新 KIP 以包含 Andrew 提出的图表请求、RPC 权限补充以及 EOS 安全性细节。
讨论围绕 KIP-1313 的重大修改展开，作者提议在请求头 v3 中引入客户端实例 ID 作为正式字段，以解决标记字段实现的复杂性。Matthias J. Sax 对此表示支持，认为这有助于 KIP-714 的兼容性，并建议版本号应采用开放式范围表示法，作者已采纳该建议并更新了提案。
@Matthias J. Sax: 支持在请求头中引入正式字段的方案，认为这对 KIP-714 的 RPC 和跨版本兼容性是巨大的改进。
@Matthias J. Sax: 建议版本号字段应使用开放式范围（如 '3+'）而非固定值，以匹配灵活版本的风格。
@Andrew Schofield: 确认已将版本属性修改为开放式范围，并同步更新了 KIP-1306 中的相关方法。
作者已根据反馈更新了 KIP 文档，将版本号改为开放式范围（如 '3+'），并补充了对 KIP-1306 的修改。
讨论主要围绕 KIP-1340 的实现细节展开，旨在解决 Streams-GlobalKTable joins 中 Join Key 的传递问题。Matthias 指出原提案可能导致 API 命名不一致，建议引入新接口；Lucy 据此提出了引入 `ValueJoinerWithKeys` 接口的新方案，以统一方法命名并提供更好的灵活性。
@Matthias J. Sax: 指出原提案仅替换部分方法会导致命名不对称，建议考虑引入新的函数式接口以允许使用统一的 `join()` 方法名。
@Lucy Liu: 采纳建议并提出了新方案：创建 `ValueJoinerWithKeys` 接口同时暴露两个 key，重载现有 `join` 方法，从而解决命名问题并增加灵活性。
@Bill Bejeck: 建议将方法命名中的 `on` 改为 `by`，并在弃用方法中添加警告注释说明 key 的行为。
Lucy 已根据反馈提出了包含新接口的改进方案及代码草稿，等待社区确认后更新 KIP。
讨论涉及 Kafka 网站依赖项 hugo-extended 的版本升级拉取请求（PR #873）。Dependabot 机器人指出该 PR 已被新的 PR #877 取代，并随之关闭了该请求。
@dependabot[bot]: PR #873 已被 PR #877 取代。
PR #873 已关闭，后续更新工作转移至 PR #877。
本次讨论主要针对 KIP-1306 中 RebalanceConsumer 接口的设计细节进行修正。参与者讨论了重复设置监听器的行为以及接口继承 AutoClosable 的安全性问题。最终作者采纳建议，决定移除公共接口中的 close 方法，仅在内部实现中管理资源。
@Matthias J. Sax: 质疑 RebalanceConsumer 继承 AutoClosable 的必要性，认为 close() 操作在再平衡期间不安全，违背了 KIP 仅暴露安全操作的初衷。
@Aditya Kousik: 承认在公共接口中暴露 close() 存在风险，决定改为在内部实现中使用 try-with-resources 模式，并已更新 KIP。
@Chia-Ping Tsai: 建议在 JavaDoc 中明确说明多次调用 setRebalanceListener 时，新监听器会替换旧监听器的行为。
作者已根据反馈更新 KIP，明确了监听器替换行为，并修正了接口设计以避免暴露不安全的 close() 方法。
本次讨论围绕 KIP-1266 展开，旨在通过压缩 RemoteLogMetadata Topic 来限制元数据消息数量。Lijun Tong 已完成代码修改并提交了 PR，采纳了之前的建议并更新了 KIP 文档。讨论中还涉及了关于删除分段消息处理逻辑及不同消息类型的考量。
@Lijun Tong: 已完成 KIP-1266 的代码实现并提交 PR，包含源码和测试更新，并采纳了社区建议。
@Lijun Tong: 建议更新 Broker 逻辑，利用新消息格式中的上下文信息处理删除操作重试，而非简单忽略。
@Jian Fu: 列举了需处理的四种消息类型，并提出了一种通过发送空键删除数据的备选方案（尽管认为该方案不够完美）。
代码实现已完成并提交 PR，等待社区进一步审查和反馈。
本周新建 42 个 Issue
本周 JIRA 重点推进了 Share Group 与 DLQ Manager 的功能实现与集成，并修复了相关的指标与数据处理问题。同时，集中修复了多处涉及 ByteBuffer 序列化的缺陷，以及 Group Coordinator 和 KRaft 模块中的稳定性问题。此外，Kafka Streams 方面也有关于 KIP-1035 的改进及模块清理工作。