mbutrovich commented on issue #11808: URL: https://github.com/apache/arrow-rs/issues/11808#issuecomment-6345239282
Thanks for raising this, @alamb. I think across all repos, reviewers are struggling to try to figure out where to spend review cycles. I think it’s a challenging conversation because in some ways people are trying to figure out what should be repo/project policies (3 non-draft PRs, etc.) and what are just personal heuristics (AI smell test of some kind). As before, I’m trying to spend cycles on community members that I feel are making strong contributions, but what that subjective criteria is can be different for each person. > I'm personally torn. On the one hand, I am frustrated that there are so many PRs that are of the form "my fuzzer found this possible overflow, here's the one line fix with 200 line test". They are real issues, that are reachable, so they should be addressed. But they haven't been seen in production, and at some point run the risk of reducing performance. I'd hate to preemptively close them, but I find myself reviewing them because they're easy to get off the review list and I can feel like I've made progress, but I really haven't because more substantive and higher impact PRs are still waiting for review. As someone who filed ~25 issues last week found by starting to experiment with building a property-based testing (PBT) library for arrow-rs, I think there is value in fixing those sorts of issues. That said, the PRs still need understanding and deep review, so I understand the added workload. In particular, PBT generates reduced tests that succinctly reproduce an issue, but that doesn’t necessarily make them good regression tests to add to arrrow-rs, and users still need to understand the scenario and design stronger tests. Also, as you said, we want to make sure the naive fixes don’t introduce performance issues. -- 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]
