💬 讨论 (8)
34 条回复 · 10 位参与者
Asif Shahid 指控其提交的 Spark PR 在原工单仍开启时，被 Committer 另立新工单并“抄袭”修复方案，谴责社区存在不道德的“卡特尔”行为。涉事 Committer Peter Toth 解释称这是在开发其他功能时独立发现并修复的问题，因未检索到现有工单导致重复，并非有意剽窃。其他社区资深成员指出这更多是大型开源项目审核资源有限导致的疏忽，而非阴谋。
@Asif Shahid: 指责社区成员通过新工单窃取其 PR 中的测试用例和修复方案，认为这是“卡特尔”成员维护私利的排他行为。
@Peter Toth: 否认抄袭，解释称是在处理其他 PR 时独立发现并修复了该 Bug，因疏忽未检查现有工单；并指出 Asif 引用的过往案例中，最终合并的方案与 Asif 的不同。
@Sean Owen / Tian Gao: 认为大型开源项目中 PR 被忽视或重复是常见现象，主要原因是审核资源不足和 JIRA 检索困难，建议贡献者通过完善 PR 质量和主动标记 Committer 来获取关注。
初步结论为沟通误会，系因 JIRA 检索疏忽和审核资源分配不均所致；社区建议贡献者保持专业态度，通过规范的流程推进代码合入，而非采取对抗性指责。
7 条回复 · 4 位参与者
讨论主要围绕 Spark 4.2.0 RC1 的发布准备展开，涉及 JDBC TABLESAMPLE 修复的紧急合并争议以及 Auto CDC 和 DSv2 事务修复的进度确认。Huaxin Gao 对 Cheng Pan 在节假日期间匆忙合并包含 API 变更的修复提出流程质疑，同时其他贡献者请求纳入关键修复。目前 RC1 将待 DSv2 事务相关 PR 合并后推进。
@Huaxin Gao: 计划发布 RC1，但指出 Cheng Pan 在美国节假日期间合并包含 API 变更的修复缺乏足够的审查时间，建议未来给予更充裕的缓冲期。
@Cheng Pan: 认为发现的 JDBC 下推问题虽非硬性阻碍但值得修复，因忽略美国节假日导致合并时间仓促，对此表示歉意。
@Anton Okolnychyi: 确认 CDC 相关问题已解决，DSv2 事务修复的 PR 已提交，预计本周末或下周初完成合并。
RC1 将在 DSv2 事务修复（SPARK-56695, SPARK-56995）合并并回溯至 branch-4.2 后发布。
2 条回复 · 2 位参与者
Aleksandr Efimov 请求 Jira 权限并提出了修复 SPARK-47017（改进 History Server 可观测性）的具体计划。Holden Karau 指导了贡献流程，说明无需分配 Jira 任务，只需留言认领即可。Aleksandr 确认理解并表示会在准备好 PR 后进行标记。
@Aleksandr Efimov: 计划通过复现问题、追踪指标断点并提交小型 PR 来改进 History Server 中 RDDScanExec 的可观测性。
@Holden Karau: 指出社区不将 Jira 问题分配给作者，建议直接在问题下留言认领，并表示愿意审查代码。
Aleksandr 将在 Jira 上留言认领该问题，并在准备好 PR 后标记 Holden Karau 进行审查。
1 条回复 · 2 位参与者
讨论主要针对 Spark 社区 CI 资源消耗严重超标（35万分钟/周 vs 25万分钟限额）的问题，急需采取措施降低用量。参与者重点探讨了调整分支合并后测试策略，倾向于通过禁用或调整 4.x 分支的测试来快速缓解资源压力。
@Tian Gao: 指出 CI 使用量已超标 40%，建议通过减少测试、加速测试或迁移定时任务等方式解决，需在两周内找到快速方案。
@Ruifeng Zheng: 建议直接禁用 4.x 分支的每次提交后测试，因为该分支仅为集成分支，RC 会从编号分支切出并保留独立 CI。
@Jungtaek Lim: 支持禁用或降低 4.x 分支测试频率，认为 master 和 4.x 分支的测试存在冗余，但也表达了对覆盖率下降的担忧。
初步达成共识，将禁用或调整 branch-4.x 的 post-merge CI 任务，以快速将资源使用量降至 ASF 限额以下。
0 条回复 · 1 位参与者
讨论旨在解决原生执行引擎内存无法作为一等公民参与 Spark 存储内存核算的长期痛点。Chang Chen 提出了让 BlockManager 管理外部引擎负载的机制，但 Kent Yao 指出该方案无法实现宣称的“统一 LRU”，因为原生块无法更新访问顺序，导致其被不公正地优先驱逐。
@Chang Chen: 指出原生引擎内存无法参与 Spark 存储内存核算的问题，并提出了让 BlockManager 管理外部引擎负载的具体机制。
@Kent Yao: 反驳了提案关于“统一 LRU”的属性，指出由于原生块无法在读取时更新其在 LinkedHashMap 中的位置，会导致其被优先驱逐，而非真正的 LRU。
@Kent Yao: 提出解决方案需明确取舍：要么引入 touch API 并承担同步查找的性能开销，要么重新定义并接受原生块的实际驱逐策略。
目前尚无定论，下一步需要提案作者回应 Kent 提出的技术质疑，即决定是否引入 touch API 及其开销，或修正关于驱逐策略的描述。
0 条回复 · 1 位参与者
讨论主要围绕 Asif Shahid 对社区处理关键数据正确性问题（SPARK-51272 和 SPARK-51016）的不满，他认为自己的贡献被低估且功劳未被正确归属。他指出问题根源在于分区器与不确定性属性之间的脱节，并质疑替代方案缺乏可靠的测试用例。目前，他已将针对不确定性 Stage Bug 的 PR 拆分为两个部分以继续推进。
@Asif Shahid: 投诉其发现并修复的关键 Bug（SPARK-51272/51016）最初被错误地标记为“无效查询”，且后续修复未给予其应有的功劳。
@Asif Shahid: 质疑替代 PR 在合并时缺乏可靠的测试用例（特别是涉及 YARN 和分区器问题的场景）。
@Asif Shahid: 强调问题的根本原因是分区器与不确定性属性之间的脱节。
作者已将针对不确定性 Stage Bug 的 PR 拆分为两个，等待社区进一步反馈。
0 条回复 · 1 位参与者
讨论主要围绕 DSv2 中列级 UPDATE 的写入模式收窄设计展开。作者已根据反馈更新了 SPIP 文档和 PR，并补充了未来支持 MERGE INTO 的设计说明，目前正寻求更多反馈以推进投票。
@Anurag Mantripragada: 在 SPIP 中新增章节，说明如何将设计扩展以支持 MERGE INTO 用例。
@Anurag Mantripragada: 已更新文档阐明 MOR 与 CoW 的优化器规则排序，确认实现能通过 ColumnPruning 有效传播模式收窄。
@Anurag Mantripragada: 请求社区在发起投票前对当前方案提供更多反馈。
暂无最终结论，下一步行动是收集社区对更新后设计（特别是 MERGE INTO 扩展）的反馈，随后将发起投票。
0 条回复 · 1 位参与者
Nimrod Ofek 提议建立结构化的入职与赞助流程，以解决新贡献者入门难和维护者负担重的问题。建议引入 AI 助手进行初步代码审查，并让资深贡献者参与指导新人，从而提升项目的可访问性与可持续性。
@Nimrod Ofek: 引入 AI 助手作为“第一审查者”，处理代码风格检查、单元测试验证等基础工作，提供即时反馈。
@Nimrod Ofek: 建立社区赞助平衡机制，期望经常提交 PR 的贡献者协助指导新人，分担核心维护者的压力。
@Nimrod Ofek: 强调培养社区和审查代码与开发新功能同等重要，有助于构建更强大的审查者队伍。
目前处于提案征集意见阶段，暂无明确结论，下一步需等待社区对该方案的讨论和反馈。