Arrow Rust 实现的新开发工作流
发布于 2021年5月4日
作者 Ruan Pearce-Authers (ruanpa)
Apache Arrow Rust 社区很高兴地宣布，其向新开发工作流的迁移现已完成！如果您正在考虑使用 Rust 作为处理列式数据的语言，请继续阅读，了解您的用例如何从我们改进的项目设置中受益。
近几个月来，社区成员一直与 Arrow 的项目管理委员会及其他贡献者密切合作，以扩展 Arrow 实现的可用工作流集。目标是定义一个新的开发流程，该流程最终将
- 在适当情况下，实现符合语义化版本的更快发布周期
- 通过统一的工具鼓励更广泛社区的最大参与
- 确保我们继续秉持Apache Way的宗旨
如果您只关注重点，这些讨论的主要成果如下：
- Rust 项目已移至单独的仓库，不再位于主 Arrow Monorepo 中
- arrow-rs 用于 Rust 中的核心 Arrow、Arrow Flight 和 Parquet 实现
- arrow-datafusion 用于 DataFusion 和 Ballista（有关这些项目的更多信息，请参阅下文！）
- Rust 社区将使用 GitHub Issues 跟踪功能开发和问题，取代 Apache 软件基金会 (ASF) 维护的 Jira 实例
- DataFusion 和 Ballista 将遵循一个新的发布周期，独立于主 Arrow 发布
但是，作为社区，我们为什么要决定改变我们的流程呢？让我们更深入地了解 Rust 实现的需求。
项目结构
Arrow 的 Rust 实现实际上由几个不同的项目组成，或者用 Rust 的术语来说，就是“crate”。除了核心 crate，即 arrow、arrow-flight 和 parquet，我们还维护
- DataFusion：一个可扩展的内存查询执行引擎，使用 Arrow 作为其格式
- Ballista：一个分布式计算平台，由 Apache Arrow 和 DataFusion 提供支持
尽管这些项目都密切相关，拥有许多共同贡献者，但它们各自的生命周期处于非常不同的阶段。核心 Arrow crate 作为规范的实现，对其他版本的 Arrow 有严格的兼容性要求，这通过严格的跨语言集成测试进行测试。
然而，另一方面，DataFusion 和 Ballista 本身仍是新兴项目，经常进行向后不兼容的更改。在旧的工作流中，DataFusion 与 Arrow 同步发布；由于 DataFusion 用户通常需要比 Arrow 发布更紧凑的调度来获取新贡献的功能或错误修复，我们发现社区中的许多人只是直接引用我们的 GitHub 仓库，而不是使用 Rust 包注册表 crates.io 上的正确版本化构建。
最终，我们决定将 Rust crate 分为两个独立的仓库：arrow-rs 用于核心 Arrow 功能，以及 arrow-datafusion 用于 DataFusion 和 Ballista。关于后者确切的发布工作流仍有待确定，但这使我们处于更好的位置，能够满足更广泛的 Rust 社区对 crate 版本控制和稳定性的期望。
社区参与
所有 Apache 项目都建立在志愿贡献之上；这是 ASF 和更广泛的开源软件开发的核心原则。在旧的 Rust 社区工作流中观察到的一个摩擦点是，要求在 Arrow 的 Jira 项目中记录问题。这一步要求潜在的贡献者首先注册一个帐户，然后获得管理工单的权限。
为了简化新社区成员的这一过程，我们决定迁移到 GitHub Issues，以跟踪新的开发工作和需要解决的已知错误，并通过从 Jira 导入各自的工单来引导我们的新仓库。创建问题来跟踪非平凡的拟议功能和增强仍然是必需的；这为社区审查提供了机会，并有助于确保尽早地在流程中提供反馈。我们希望这能在组织和新贡献者的可访问性之间取得更好的平衡。
参与进来
为了进一步改进新 Arrow 贡献者的入职流程，我们已开始在 arrow-rs 和 arrow-datafusion 中将选定的问题标记为“good first issue”。这些问题范围小，但仍是对项目有价值的贡献，并帮助新社区成员熟悉我们的开发工作流和工具。
不确定从何开始处理某个特定问题，或者想了解我们项目之一的状态？加入 Arrow 邮件列表或 ASF Slack 服务器上的 #arrow-rust 频道。
总结
最后一点：这里没有任何内容旨在作为规定性建议。作为一个社区，我们决定这些流程最适合我们项目目前的状况，但这可能会随着时间而改变！毕竟，软件工程没有银弹。