Xuanwo commented on issue #1797: URL: https://github.com/apache/iceberg-rust/issues/1797#issuecomment-3480389354
Thank you all for joining this discussion. This thread hasn’t been active for a while, so let me summarize. I’ll also list the next steps as issues. Some of these are already comments from @liurenjie1024, but putting them all in one place makes it easier to read and track. > Please note that this summary includes my personal opinions and preferences, it’s not an official response from the iceberg-rust community. ## Review is currently the bottleneck Many people mentioned that review is the current bottleneck. That’s also my personal feeling. Some suggested we should engage more people to join reviews and encourage contributors to split PRs into smaller chunks to make them easier to review. Those suggestions are absolutely true and valid. But I also feel we can adapt our review style somehow. Instead of requiring contributors to address all issues, we can encourage them to create follow-ups (note: these don’t need to be finished by the same person). Some of these follow-ups make great first issues that can help more people join the community. I created an issue https://github.com/apache/iceberg-rust/issues/1815 to track this. ## Iceberg Rust is too Java-like This concern is also true: iceberg-rust itself feels too much like Java. It’s partly the history of how iceberg-rust was decided. The early core group of contributors consisted of two kinds of people: one group familiar with Iceberg but not yet experienced in Rust, who wanted to learn Rust by contributing to iceberg-rust; the other group familiar with Rust but knowing very little about Iceberg, who wanted to learn more about Iceberg through contribution. So in either case, following the same pattern from Java wasn’t a bad option. Otherwise, we wouldn’t have been able to build iceberg-rust into its current shape. The other reason, as @Twuebi and @liurenjie1024 mentioned, is that although Iceberg has a great spec and the spec intends to be language-agnostic and allow different languages to have their own implementations, that never truly happened. In reality, many things aren’t defined or clearly spelled out in the Iceberg spec, so we have to refer to Iceberg-java’s current behavior to make things work. I’m not here to defend ourselves. It’s just the reality we’re facing. To improve in this area, we need to find a way to make our implementation correct and gradually improve it to be more friendly to Rust users. I’ve opened this issue https://github.com/apache/iceberg-rust/issues/1816 to collect feedback on coding style. ## Iceberg Kernel I think it’s a great idea to split iceberg-kernel so we can separate the planning and execution stages. We can follow delta-rs’s pattern to build it, providing a good abstraction for users to implement their own engine. In this kernel, we’ll let users plug in their own file IO and execution engine. I’ve started this issue https://github.com/apache/iceberg-rust/issues/1817 to track progress on iceberg-kernel. ## Feature requests Some people mentioned specific issues like: - https://github.com/apache/iceberg-rust/pull/1486 - https://github.com/apache/iceberg-rust/issues/1604 We can revisit them when needed. — All the issues I mentioned previously have been collected in tracking issue https://github.com/apache/iceberg-rust/issues/1818. Feel free to add more feedback. We’ll track it in the same issue. We’ll keep this issue open until it’s no longer an issue. Thank you everyone for joining the discussion and sharing your honest feedback again. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
