2026-05-04 ~ 2026-05-10
Peter Toth 投了 +1 (non-binding)，并未提出异议，而是延长了投票截止时间。
Peter Toth 提议发布 Apache Spark 4.1.2，指出自 4.1.1 版本以来已积累约 100 个未发布的提交，并自愿担任发布经理。该提议获得了社区的广泛支持，多位核心贡献者投票表示赞同。Peter Toth 随后确认收到反馈，准备推进发布流程。
@Peter Toth: 提议发布 4.1.2 并自愿担任发布经理，理由是分支上已有约 100 个未发布提交。
@Dongjoon Hyun: 支持发布，认为验证这些提交对 Spark 4.1 和 4.2.0 版本都有很大帮助。
@Hyukjin Kwon / Wenchen Fan 等: 一致投票 +1，同意启动发布流程。
社区达成共识，同意发布 Apache Spark 4.1.2，Peter Toth 将作为发布经理负责后续工作。
讨论主要围绕 Spark 纳秒时间戳的内部实现方案展开，对比了 Xiaoxuan Li 提出的 INT64 方案与 Max Gekk 提出的复合类型（micros + nanos of micro）方案。核心争议在于性能开销与 SQL 标准合规性（年份范围 0001-9999）之间的权衡，最终讨论倾向于为了满足 SQL 标准而放弃 INT64 方案。
@Xiaoxuan Li: 担心复合类型会导致性能下降（内存占用增加、缓存局部性变差），且超出 INT64 范围的数据在输出到 Parquet/Arrow 等主流格式时会遇到兼容性瓶颈。
@Max Gekk: 强调必须符合 SQL 标准（年份范围 0001-9999），INT64 无法满足此需求；认为复合方案的性能损耗可控，并反驳了支持皮秒精度的建议，指出 Java 生态限制和额外的内存开销。
@Wenchen Fan: 明确指出新类型应遵循 SQL 标准，这实际上排除了 INT64 方案，建议对不兼容的输出格式抛出越界错误或推动社区支持。
Max Gekk 提议若无异议将启动 SPIP 投票流程。
Huaxin Gao 提议设立每月 Spark 社区同步会议以促进实时讨论，Mark Hamstra 起初担忧这不符合 Apache 邮件列表优先的原则。经 Huaxin 澄清邮件列表仍为决策唯一来源且会议纪要将回馈社区后，该提议获得多方支持。
@Huaxin Gao: 提议每月同步会议，并澄清邮件列表仍将是社区讨论和决策的事实来源，会议结果将汇总回邮件列表。
@Mark Hamstra: 强调 Apache 准则（“如果没发生在邮件列表上，那就是没发生”），要求会议总结必须发回列表且行动需经列表讨论方可接受。
@Holden Karau: 支持提议，认为社交层面（社区优于代码）有益，建议轮换会议时间以方便更多人参与。
社区原则上同意该提案，前提是必须确保邮件列表作为决策的唯一来源。下一步将由发起人设置议程文档并提议具体会议时间。
讨论主要围绕如何应对新发布节奏下的 CI 资源开销问题，特别是针对非活跃分支的 CI 策略。目前 branch-3.5 的 CI 处于损坏状态，社区成员正在积极修复并探讨通过优化测试选择或降低运行频率来缓解压力。
@Akira Ajisaka: 正在修复 branch-3.5 的 CI 故障，并赞同降低非活跃分支的 CI 运行频率。
@Tian Gao: 指出 Java 测试开销较大，不应仅通过降低覆盖率来解决问题，需探索更智能的 CI 优化方案。
@Holden Karau: 认为“更智能的测试选择”是解决 CI 问题的关键手段，尽管实施起来需要投入精力。
初步达成降低非活跃分支 CI 频率的共识；Akira Ajisaka 正在跟进修复 branch-3.5 的 CI 问题，Tian Gao 将着手处理 CI 优化的易行事项（low hanging fruits）。
用户发现 Spark ML 模型训练过程中，ClosureCleaner 因重复加载和解析相同的类元数据导致性能瓶颈。建议引入有界的 LRU 缓存（如使用 Guava）来优化类分析过程，并提供了测试数据佐证。目前正征求社区意见以决定是否提交 JIRA。
@Ángel Álvarez Pascua: 性能分析显示 RDDLossFunction 等类在 ClosureCleaner 中被重复加载和解析数千次，消耗大量运行时间。
@Ángel Álvarez Pascua: 建议在 ClosureCleaner 中添加有界、可配置的缓存（如 Guava cache）以复用类元数据。
@Ángel Álvarez Pascua: 实施缓存时需注意排除或谨慎处理 lambda 及动态生成的类。
暂无社区回复，发件人计划在进一步确认后开启 JIRA 工单并提出补丁。
该讨论主要关于 DSv2 中列级 UPDATE 的写入模式缩窄优化方案。Anurag Mantripragada 已根据反馈更新了 PR 和 SPIP 文档，并详细解释了针对 MOR 和 CoW 两种模式在优化器规则处理上的差异及实现策略，目前正寻求进一步反馈以推进投票。
@Anurag Mantripragada: 已根据初步反馈清理了 PR 和 SPIP 文档，呼吁社区在投票前审查具体方案。
@Anurag Mantripragada: 对于 MOR (WriteDelta) 模式，方案利用 ColumnPruning 和 V2ScanRelationPushDown 自然实现了列裁剪。
@Anurag Mantripragada: 对于 CoW (ReplaceData) 模式，由于优化规则执行顺序较早，需在分析阶段手动缩窄 DataSourceV2Relation 的输出。
已明确 MOR 和 CoW 的技术实现差异，下一步等待社区反馈并准备发起投票。
讨论主要关注如何应对日益增长的软件供应链攻击，特别是关于 PySpark 依赖项的固定问题。参与者探讨了是否需要锁定依赖版本，或者仅发布构建时的版本信息以供审计。目前倾向于在不影响常规使用的前提下，提供更透明的依赖版本信息。
@Holden Karau: 建议暂不锁定依赖，但应在 CI 过程中发布构建所用的包版本。
@Devin Petersohn: 建议提供带有上限依赖的安装目标（如 `pyspark[deps-upper-bounded]`），在不影响常规使用的情况下提供保护。
@Cheng Pan: 支持发布测试环境的依赖版本信息，参考 Java/Scala 的现有做法，确保用户知晓测试所用的确切版本。
初步倾向于发布测试时的依赖版本信息（如 pip freeze 输出），而非直接锁定依赖，具体实施细节待定。
本周新建 0 个 Issue
本周无新建 JIRA。