Arrow 的 Rust 实现的新开发流程


已发布 2021 年 5 月 4 日
作者 Ruan Pearce-Authers (ruanpa)

Apache Arrow Rust 社区很高兴地宣布,它向新开发流程的迁移现已完成!如果您正在考虑将 Rust 作为处理列式数据的语言,请继续阅读并了解您的用例如何从我们新的和改进的项目设置中受益。

最近几个月,社区成员一直与 Arrow 的项目管理委员会和其他贡献者紧密合作,以扩展 Arrow 实现的可用工作流程集。目标是定义一个新的开发流程,最终

  • 实现更快的发布节奏,并在适用的情况下遵循 语义化版本控制
  • 通过统一的工具鼓励更广泛的社区最大程度地参与
  • 确保我们继续坚持 Apache 之道 的原则

如果您只是为了解重点,那么这些讨论的主要成果如下

  • Rust 项目已移至主 Arrow 单一代码库 之外的单独存储库
    • arrow-rs 用于 Rust 中的核心 Arrow、Arrow Flight 和 Parquet 实现
    • arrow-datafusion 用于 DataFusion 和 Ballista(更多关于这些项目的信息如下!)
  • Rust 社区将使用 GitHub Issues 来跟踪功能开发和问题,取代 Apache 软件基金会 (ASF) 维护的 Jira 实例
  • DataFusion 和 Ballista 将遵循新的发布周期,独立于主要的 Arrow 发布

但是,作为一个社区,我们为什么要决定改变我们的流程呢?让我们更深入地了解一下 Rust 实现的需求。

项目结构

Arrow 的 Rust 实现实际上由几个不同的项目组成,或者用 Rust 的说法,“crates”。除了核心 crates,即 arrowarrow-flightparquet,我们还维护

  • DataFusion:一个使用 Arrow 作为其格式的可扩展内存查询执行引擎
  • Ballista:一个由 Apache Arrow 和 DataFusion 提供支持的分布式计算平台

虽然这些项目都密切相关,并且有许多共同的贡献者,但它们各自的生命周期却处于非常不同的阶段. 核心 Arrow crate 作为规范的实现,对其他版本的 Arrow 有严格的兼容性要求,并且通过严格的跨语言集成测试来测试这一点。

然而,另一方面,DataFusion 和 Ballista 本身仍是新兴项目,它们经常进行向后不兼容的更改。在旧的工作流程中,DataFusion 与 Arrow 同步发布;由于 DataFusion 用户通常需要比 Arrow 发布更紧凑的计划来获取新贡献的功能或错误修复,我们观察到社区中的许多人只是简单地引用我们的 GitHub 存储库,而不是在 Rust 的包注册表 crates.io 上使用正确版本化的构建。

最终,我们决定将 Rust crates 分成两个独立的存储库:arrow-rs 用于核心 Arrow 功能,arrow-datafusion 用于 DataFusion 和 Ballista。在确定后者的确切发布工作流程方面仍有工作要做,但这让我们能够更好地满足更广泛的 Rust 社区对 crate 版本控制和稳定性的期望。

社区参与

所有 Apache 项目都建立在志愿者贡献的基础上;这是 ASF 和更广泛的开源软件开发的核心原则。尤其是在 Rust 社区的先前工作流程中观察到的一个摩擦点是,需要在 Arrow 的 Jira 项目中记录问题。此步骤要求潜在的贡献者首先注册一个帐户,然后获得管理工单的权限。

为了简化新社区成员的流程,我们决定迁移到 GitHub Issues 来跟踪新的开发工作和需要解决的已知错误,并通过从 Jira 导入各自的工单来引导我们的新存储库。仍然需要创建问题来跟踪非琐碎的拟议功能和增强功能;这为社区审查创造了机会,并有助于确保在流程的早期提供反馈。我们希望这能在组织和潜在贡献者的可访问性之间取得更好的平衡。

参与进来

为了进一步改进 Arrow 新贡献者的入门流程,我们已经开始在 arrow-rsarrow-datafusion 中将选定的问题标记为“good first issue”。这些问题的范围很小,但仍然是对项目的有价值的贡献,并帮助新社区成员熟悉我们的开发工作流程和工具。

不确定从哪里开始处理特定问题,或者对我们某个项目的状态感到好奇?加入 Arrow 邮件列表ASF Slack 服务器上的 #arrow-rust 频道。

结语

最后一点:这里没有任何内容旨在作为规范性建议。作为一个社区,我们已经决定这些流程最适合我们项目的当前状态,但这可能会随着时间的推移而改变!毕竟,软件工程没有银弹