Hi all, Thanks for bringing this up.
I would like to add that I have experienced similar bottlenecks within the Spark connector area, where limited reviewer bandwidth frequently delays progress. We have tried to bring committers and contributors together via separate syncs <https://docs.google.com/document/d/19nno1RoPznbbxKOZZddZNHHafa7XULjbN6RPExdr2n4/edit?tab=t.0#heading=h.r977qio1wsv2> for Spark, but we remain bottlenecked. While I generally agree with the points raised regarding the need to increase the number of committers to address these concerns, I believe this should not in any way circumvent the qualities and standards described in our committer guidelines <https://iceberg.apache.org/community/#how-do-i-demonstrate-those-qualities> . I would love to hear what PMC thinks. ~ Anurag On Thu, May 28, 2026 at 12:51 PM Jared Yu <[email protected]> wrote: > Hi Jordan, > > I would also like to thank you for bringing this up to the broader > community. I'm currently focusing on contributing to PyIceberg and > currently share many of the viewpoints you mentioned. I messaged someone > about this before, noting that PyIceberg seems quite bottlenecked by the > small handful of people in charge of merging. That person said they could > bring up the idea of adding more committers to the project, perhaps that in > itself would be a viable option? For Iceberg-Rust, maybe there are some > reliable and frequent unofficial reviewers who have been contributing > steadily over the past months/years. It would be nice if the community > could help nominate them and bring them to the attention of the maintainers > so they can potentially be added as committers to help speed up the process > of getting the bindings on parity with Java. I think this would greatly > help all the current Iceberg bindings. > > On Thu, May 28, 2026 at 11:29 AM Shawn Chang <[email protected]> > wrote: > >> Hi Jordan, >> >> Thanks for bringing this to a broader discussion. >> >> I totally agree that we have a reviewer bottleneck in the iceberg rust >> community. This trend seems common across many open source projects, >> especially since AI-assisted coding became the norm, while AI-assisted >> reviewing doesn’t provide equivalent confidence to project maintainers. >> >> Outside reviews are always welcome and are usually very helpful. >> Personally, I’ve learned a lot from review comments in general, not just >> from the Iceberg maintainers. Ultimately, the responsibility for ensuring >> code quality falls on the person who clicks the merge button. I’m not sure >> if we can address the bottleneck immediately, but I’m very curious to hear >> what other members think about it. >> >> We really want to hear and discuss ideas around the project direction >> through multiple channels, including the email thread, slack, GitHub >> Discussions, and the rust community syncs. In fact, we just discussed some >> of the items you mentioned, such as delete manifest processing support, >> during the iceberg rust community sync earlier today. Besides that, we also >> discussed adding metadata-level variant support, encryption support, etc., >> and I believe these all align with the feature parity goals. >> >> Looking forward to hearing other thoughts here! >> >> Best, >> Shawn >> >> On Thu, May 28, 2026 at 9:29 AM Jordan Epstein <[email protected]> >> wrote: >> >>> Happy Thursday, everyone! >>> >>> I wanted to try and kick off a discussion here regarding seeing what we >>> could do about iceberg-rust and increasing the amount of review bandwidth >>> there. Obviously, we're constrained to some degree on all of the iceberg >>> projects but this one is gaining a lot of traction and I've heard >>> anecdotally of many projects beginning to maintain their own forks here >>> because getting code reviewed is just too much of a challenge. >>> >>> Given that these projects in other languages are generally just trying >>> to achieve feature parity with Java, it really diminishes them when key >>> features are missing. >>> >>> In iceberg-rust, for example: >>> - No positional delete writing support >>> - No deletion vector writing support >>> - No HDFS support >>> >>> One idea that I have to increase reviewer bandwidth here could be to >>> take some key stakeholders from many of the existing OSS rust-based iceberg >>> projects and add them here? E.g. somebody (trusted) from DataFusion >>> (Comet), RisingWave, DataBend, Polars. Perhaps there are also some major >>> companies in the space that might like representatives (for example I see >>> Amazon, Microsoft, Apple, Palantir in there). Then that person could at >>> least be the point-person for reviews that are necessary for features in >>> those upstream codebases. To be clear, I'm mainly suggesting that these >>> people are given mandates to review changes to get these projects to parity >>> with the Java versions, and less so focusing on bespoke features specific >>> to one language. >>> >>> I understand that we want all would-be contributors to review as well, >>> but I can come up with a few examples where a change is reviewed adequately >>> by somebody that lacks permissions, and then it eventually goes idle since >>> nobody can supply the approval. >>> >>> Let me know what you think! Thank you! >>> >>> Best, >>> Jordan Epstein (IMC Trading) >>> >> > > -- > Best regards, > > Jared Yu > B.S. Statistics - University of California, Davis '19 > M.S. Data Science - Johns Hopkins University '22 >
