FANNG1 commented on PR #11060: URL: https://github.com/apache/gravitino/pull/11060#issuecomment-4456530942
Thanks for adding the matrix runners and documenting how to re-verify the Lance compatibility ranges. I think the CI strategy here needs to be called out explicitly before we merge this. My concern is that the full compatibility matrix should probably not become part of the default PR validation path. These tests are expensive, depend on external package ecosystems, and can become noisy when PyPI / Maven resolution changes upstream. That makes them a poor fit for the main per-PR signal. What seems more sustainable is a two-layer approach: 1. Keep one pinned, known-good Lance combination in the normal CI path as the regression guard. 2. Keep the full multi-version matrix as a separate automation path: scheduled workflow, release-time validation, and manual dispatch when we need to re-verify or extend the compatibility claims. That would still keep the matrix exercised continuously enough to avoid script rot, but without making every PR pay the cost or absorb upstream ecosystem flakiness. If we go this direction, I also think the matrix runner should avoid floating dependencies by default (for example, not resolving `lance-namespace` as unpinned `latest`). Can we align on that execution model in this PR? Right now the tasks and docs are being added, but the intended automation boundary is still unclear. -- 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]
